lilith/Todo: explain lifetimes better in the Rust Book

## Todo: explain lifetimes better in the Rust Book
<nathanael> Why does rust care about lifetime bounds on pointers to generic types?
<delma> iamrohit7: yes if you represent graph like that
* rschiffl1n has quit (Ping timeout: 121 seconds)
<Moonlightning> iamrohit7: I guess. And to remove a node, you'd...have to travel to each of its neighbors in turn, removing that edge and the dropping neighbor's Rc holding self, and then use Rc::try_unwrap()
<delma> there is other reprentantions too
<Moonlightning> Or...unsafe black magic
* mou has quit (Ping timeout: 121 seconds)
<Moonlightning> dinfuehr: names instead of just ids?
<nathanael> Ex: https://gist.github.com/nathanaeljones/80792ff3ffb5854f7a18ba40f60c6770
<Moonlightning> dinfuehr: AFAIK, Display is only for types that have a single obvious human-readable representation. It's not implemented for most types.
<iamrohit7> delma: yeah. the matrix one.
<Moonlightning> dinfuehr: You might consider not implementing it, and just adding methods for formatting in the various different ways. I'm sure there must be a precedent for how to do that, but I don't know of one.
<delma> yeah or just vector and indices
<Arnavion> dinfuehr: You can have a function that takes in the parameter and returns another object that implements Display
<delma> !crate petgraph
<rustbot> petgraph (0.4.1) - Graph data structure library. Provides graph types and graph algorithms. -> https://crates.io/crates/petgraph <https://docs.rs/crate/petgraph>
<Arnavion> dinfuehr: For example   https://doc.rust-lang.org/std/path/struct.Path.html#method.display
* dionysus69 has quit (Ping timeout: 121 seconds)
<Moonlightning> dinfuehr, Arnavion: Oh, that's a good idea.
<fqtw> when to use T: ?Sized and when T: Sized ?
* solenodic has quit (Ping timeout: 121 seconds)
<delma> trait that says that type has staticly known size
<iamrohit7> are objects in Rc allocated in the heap too?
<dinfuehr> Arnavion: yeah that's true, I will try to implement it this way
<Moonlightning> iamrohit7: yes--they have to be.
<Moonlightning> iamrohit7: they can't be allocated on any one stack frame, because there might be other `Rc`s elsewhere keeping the value alive
* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
<Moonlightning> nathanael: genericized types get dropped just like non-genericized types!
<iamrohit7> Moonlightning: delma: thanks for the help.
<Moonlightning> You're welcome, iamrohit7. :)
* lucian (lucian@moz-7hsb6f.cable.virginm.net) has joined
* sp3d has quit (Connection closed)
* rschiffl1n has quit (Ping timeout: 121 seconds)
<Moonlightning> nathanael: also, those're references--pointers exist in Rust, and are /very/ different things.
<iamrohit7> Moonlightning: last question, clone on an Rc increments the counter?
* ideasman42 (cambo@moz-hf4pn0.iinet.net.au) has joined
<delma> yeah
<delma> and Drop implementation decrements
* ygrek has quit (Ping timeout: 121 seconds)
<iamrohit7> delma: Drop is manually implemented for it?
* foser___ has quit (Client exited)
<Moonlightning> iamrohit7: you may want to check out the documentation for Rc ( https://doc.rust-lang.org/std/rc/ )
<iamrohit7> Moonlightning: yeah, sure.
<phaazon> iamrohit7: I think automatic Drop impl doesn’t have a sense
<phaazon> but I might be mistaken
<phaazon> any*
* MikeIon (michael@moz-qm3.0ef.126.1.IP) has joined
<nathanael> Moonlighting: *mut T is a reference?
* futile (felix@moz-6ii5jc.dip0.t-ipconnect.de) has joined
<phaazon> nathanael: a pointer
* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
* solenodic (solenodic@moz-o2k.dlj.109.66.IP) has joined
<nathanael> Rust reasons about lifetimes for pointers?
<Moonlightning> nathanael: pointers in Rust should be used very sparingly--they're `unsafe` and only really exist for low-level implementations and rare cases in which references don't suffice.
<phaazon> nathanael: no
<phaazon> pointers are unsafe
<Moonlightning> nathanael: it doesn't; you have to do that yourself. That's one reason they're so `unsafe`!
<phaazon> you cannot tag them with lifetimes
* kerrick has quit (Ping timeout: 121 seconds)
<nathanael> That's why I'm confused by the error message "the parameter type `T` may not live long enough" when T is only used as a pointer type.
<phaazon> if you’re not doing something very very specific or tweaking performance for very low level code, you won’t need pointers
<phaazon> nathanael: show the code
<phaazon> that’s typically because you lack a constraint on your T type
<nathanael> https://gist.github.com/nathanaeljones/80792ff3ffb5854f7a18ba40f60c6770
* rschiffl1n has quit (Ping timeout: 121 seconds)
<phaazon> yeah
<phaazon> you box your T
<phaazon> by default, a Box requires its parameter to live as long as your program
<phaazon> you have to explain more about your problem
<phaazon> to put the correct lifetime
<phaazon> or
<nathanael> So what's the best way to register callbacks that mutate their parameters
<phaazon> in your where clause
<phaazon> add T: 'static
<phaazon> but I kinda discourage that and either put the correct lifetime in the box
<phaazon> nathanael: that’s a very general problem, there’s no such thing as “the best way” :)
* breadmenace^ has quit (Ping timeout: 121 seconds)
<Moonlightning> fqtw: so how about those prev_power_of_two() usecases? I know I'd like to see it added
* findow (Mibbit@moz-akf720.hsi3.kabel-badenwuerttemberg.de) has joined
<fqtw> Moonlightning: im using next_power_of_two() and divide by two now
<nathanael> I tried adding a lifetime in the box. Perhaps I'm misunderstanding the effect of adding + 'static
<phaazon> nathanael: what lifetime did you add?
<phaazon> Box<T> and Box<T + 'static> are exactly the same, just for you to know
<phaazon> so if you use Box<T>, you need T: 'static
<phaazon> though, if you have a better lifetime than that
<phaazon> you can do Box<T + 'a> where T: 'a
* mkraemer has quit (Quit: WeeChat 1.5)
* J_Arcane (J_Arcane2.0@moz-ji1s4d.bb.dnainternet.fi) has joined
<nathanael> So you can 'downgrade' from 'static to something more restrictive in a box?
<Moonlightning> fqtw: note that next_power_of_two() returns self if self.is_power_of_two()
<phaazon> yep
<phaazon> that will tell for which lifetime the box is valid
<phaazon> for instance:
<fqtw> Moonlightning: yea but that doesnt happen because i partition() those away beforehand
* mkraemer (mkraemer@moz-nodm6n.marius-kraemer.de) has joined
<nathanael> (non-reduced code): https://gist.github.com/nathanaeljones/95a3a61d50620ee19190b69741dc7e8d
<phaazon> struct Foo<'a, T> where T: 'a { box: Box<T + 'a> }
<phaazon> that will restrict the Box to Foo
<phaazon> if your Foo dies, the Box dies
<phaazon> Box<Fn(*mut T, &[u8]) + 'a>
<phaazon> and same for the other box
<phaazon> though, why using pointers?
* breadmenace (breadmenac@moz-99sjhj.sntcca.sbcglobal.net) has joined
* Moonlightning wonders what's up with that point--yeah.
<nathanael> What qualifies as 'static, though?
<phaazon> anything that can live as long as your program
<phaazon> Box allocates on the heap, so by default, and because it doesn’t have a lifetime, it cannot know which lifetime the inner value has
<phaazon> so it’s 'static by default
<nathanael> I.e, readonly data segment? Or something that Owned and has that potential, if stored somewhere static?
<findow> Hi, I want to add a linker path to cargo. Up to now I just added env RUSTFLAGS="-L./", but when running `cargo help rustc` it suggests tohat I can use the build.rustfalgs option. But I couldn't get it working in cargo.toml.  Does anybody know how to set this option?
* futile has quit (Quit: WeeChat 1.6)
* MikeIon has quit (Ping timeout: 121 seconds)
* foser___ (foser@moz-g0ha5f.dynamic.ziggo.nl) has joined
<phaazon> nathanael: 'static doesn’t give any information about mutability
<nathanael> So, for example D in this instance is a cloneable owned type with no references. T is ephemeral and only created for the purpose of executing these functions. Each instance of T will outlive the function call, but no more. We're not capturing T.
<phaazon> it’s just a lifetime
<phaazon>     pub fn invoke<'f,'b,'c,'d,'e>(&'f self, upon: &'b mut T, method: &'c str, json_request_body: &'d [u8]) -> Result<JsonResponseBuf>{
<phaazon> I really wonder what you’re doing :D
<phaazon> you should use lifetime ellision pal!
<nathanael> I'm trying to do middleware helpers with closures, basically. A recent refactor made that eligible for elision :)
* ur5us has quit (A TLS packet with unexpected length was received.)
* ur5us (ur5us@moz-belaqk.ihug.co.nz) has joined
* montanonic has quit (Ping timeout: 121 seconds)
* descender has quit (Quit: ...)
* vvv has quit (Ping timeout: 121 seconds)
* jensnockert (jensnockert@moz-34v09j.corp.bahnhof.se) has joined
* ur5us has quit (Ping timeout: 121 seconds)
* Trangar has quit (Connection closed)
* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
* Philpax (Philpax@moz-5lrr6m.optusnet.com.au) has joined
* arBmind has quit (Quit: Leaving.)
* shellac (pldms@moz-lngnj4.bris.ac.uk) has joined
* rschiffl1n has quit (Ping timeout: 121 seconds)
* junqed (junqed@moz-6jq.3fb.70.178.IP) has joined
* quasisphere has quit (Ping timeout: 121 seconds)
<nathanael> So &'static and 'static have completely different meanings?
* Morten (Morten@moz-9bcmlg.eduroam.uib.no) has joined
* fqtw_ (me@moz-r6jb71.dyn.telefonica.de) has joined
<Moonlightning> 'static is a lifetime. It means that the type is allowed to live for the entire lifetime of the program.
<nathanael> Because this compiles and I have no idea why: https://gist.github.com/nathanaeljones/168db41ad358404e5c35828da1438afe
<nathanael> Whereas &'static means it is required to live for the life of the program?
<Moonlightning> Owned types are always 'static. Reference types must be borrowed from an owned type, and have strict restrictions on their lifetimes.
* fqtw has quit (Ping timeout: 121 seconds)
<nathanael> Can "Owned types are always 'static." go somewhere prominent?
* MikeIon (michael@moz-cp5m5a.dodo.net.au) has joined
* Trangar (Trangar@moz-j8f.r0d.78.77.IP) has joined
<Moonlightning> Heheh, yeah. I only learned that recently.
* Morten has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
<nathanael> Like page 1 would be nice.
<Moonlightning> The `&` sigil is a little confusing, because other stuff--like the `mut` keyword and a lifetime--can go /after/ it, but before the underlying type name.
<nathanael> Thank you for opening a new world for me. I've been struggling with this for months.
<Moonlightning> &T has a lifetime; it's just elided. It /might/ be &'static T; it might be something else.
<nathanael> And 'a,'b,'c,'d,'e,'f,'g,'h,'i,'j,'k ing myself to death.
<Moonlightning> Er...double-check that. >.>
* junqed has quit (Ping timeout: 121 seconds)
<nathanael> Only within a function, right? At signature boundaries elision of lifetimes to the lowest expectation means the potential of the lifetime is unrecoverable, right?
<Moonlightning> nathanael: You often don't have to specify the lifetime. See the Book's bit on elision.
* kamil has quit (Quit: Leaving...)
* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
<nathanael> I know the rules for elision. I didn't grasp that Owned implied 'static. Everything hinted the opposite, or that Owned had a special lifetime category orthogonal to lifetime bounds.
<Moonlightning> Uh...
* montanonic (nicholas@moz-u3evs7.or.comcast.net) has joined
<Moonlightning> Oh, /owned/ wasn't an identifier there; by it, I only meant...not behind a reference (or pointer, I guess)
<Moonlightning> y'know..owned. XD
* mib_8lfkui (Mibbit@moz-p4b.j64.37.103.IP) has joined
* mib_8lfkui has quit (Quit: http://www.mibbit.com ajax IRC Client)
* chris_99 (chris_99@moz-lel5jk.ir6t.2uic.04f8.2a01.IP) has joined
<skade> How does Owned imply static? If I own something that has &'a references, it cannot be static?
* rschiffl1n has quit (Ping timeout: 121 seconds)
* safwan (uid93576@moz-va2btc.charlton.irccloud.com) has joined
<Moonlightning> skade: all owned types are 'static, but not all 'static types are owned.
* solenodic has quit (Ping timeout: 121 seconds)
<nathanael> I just deleted 2/3rds of the lifetime specifiers from my (sizeable) codebase via regex. And it compiles.
<nathanael> With two strategic insertions of 'static
<skade> Box<Iterator<Item=Foo>> over &'a [Foo] is definitely owned, but has 'a as a lifetime
* rubdos has quit (Ping timeout: 121 seconds)
* jensnockert has quit (Connection closed)
<skade> (Which is the most common case I can think of, where you need to override the standard lifetime of a Box)
<ubsan> skade: I had not thought of that
<ubsan> gg
* tormoz has quit (Connection closed)
* jensnockert (jensnockert@moz-34v09j.corp.bahnhof.se) has joined
<ubsan> skade: Box<&'a Foo> also works
<skade> right, though that's a bit odd :D
<ubsan> just a bit :P
* tormoz (geov@moz-3q6.afp.124.178.IP) has joined
<Moonlightning> So, wait, that makes the Box not `'static`?
<ubsan> yeah
<ubsan> it's 'a
<skade> sure, if it were static, it could outlive the collection
<skade> i'll write you an example
<Moonlightning> Okay, I buy it.
<skade> (but you need the box, due to dynamic dispatch)
<Moonlightning> I generalized that too much.
<Moonlightning> Someone said `String`s are always 'static...which is true, because you can't stuff a reference into a String >.>
<skade> The notiation in that case is `Box<Iterator<Item=Foo>> + 'a`
* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
* thvdburgt (thvdburgt@moz-pgac4k.direct-adsl.nl) has joined
<Moonlightning> So, instead..."anything that doesn't have an explicit or inferred lifetime parameter is 'static"?
* khades has quit (Connection closed)
* seu has quit (Quit: No Ping reply in 180 seconds.)
* kamil (kamil@moz-d3c3p3.play-internet.pl) has joined
* Trangar has quit (Quit: Leaving)
* seu (quassel@moz-eg8m2t.re) has joined
<Moonlightning> /ping nathanael. Sorry. >.<;
<nathanael> Moonlightning: Do not apologize - this has been the most enlightening conversation on IRC for me.
<Moonlightning> Heh :P
* rschiffl1n has quit (Ping timeout: 121 seconds)
<Moonlightning> owned does not, in fact, imply 'static
<Moonlightning> but 'static is also not only for references. Which is kinda counterintuitive.
<Moonlightning> So, I guess...if a type's lifetime is not restricted because it was borrowed, then its lifetime is 'static.
* SuperFluffy (janis@moz-2gk4sp.customers.d1-online.com) has joined
* rkruppe (chatzilla@moz-o3kq3g.p5eo.1gvm.41b8.2001.IP) has joined
<nathanael> That's a superset of Owned without lifetime specifiers.
* frankpf (frankpf@moz-npu.red.162.150.IP) has joined
* frankpf_ (frankpf@moz-npu.red.162.150.IP) has joined
<nathanael> I think a table of examples with effective lifetime annotations would help the Book a lot.
* [steveklabnik] is away (catch you later)
* Ping reply from steveklabnik: 1.08 second(s)
<Moonlightning> Should maybe open an issue for that
<nathanael> I'll save this chat log and put it on my insanely long todo list.
	<nathanael> Why does rust care about lifetime bounds on pointers to generic types?
	<delma> iamrohit7: yes if you represent graph like that
	* rschiffl1n has quit (Ping timeout: 121 seconds)
	<Moonlightning> iamrohit7: I guess. And to remove a node, you'd...have to travel to each of its neighbors in turn, removing that edge and the dropping neighbor's Rc holding self, and then use Rc::try_unwrap()
	<delma> there is other reprentantions too
	<Moonlightning> Or...unsafe black magic
	* mou has quit (Ping timeout: 121 seconds)
	<Moonlightning> dinfuehr: names instead of just ids?
	<nathanael> Ex: https://gist.github.com/nathanaeljones/80792ff3ffb5854f7a18ba40f60c6770
	<Moonlightning> dinfuehr: AFAIK, Display is only for types that have a single obvious human-readable representation. It's not implemented for most types.
	<iamrohit7> delma: yeah. the matrix one.
	<Moonlightning> dinfuehr: You might consider not implementing it, and just adding methods for formatting in the various different ways. I'm sure there must be a precedent for how to do that, but I don't know of one.
	<delma> yeah or just vector and indices
	<Arnavion> dinfuehr: You can have a function that takes in the parameter and returns another object that implements Display
	<delma> !crate petgraph
	<rustbot> petgraph (0.4.1) - Graph data structure library. Provides graph types and graph algorithms. -> https://crates.io/crates/petgraph <https://docs.rs/crate/petgraph>
	<Arnavion> dinfuehr: For example https://doc.rust-lang.org/std/path/struct.Path.html#method.display
	* dionysus69 has quit (Ping timeout: 121 seconds)
	<Moonlightning> dinfuehr, Arnavion: Oh, that's a good idea.
	<fqtw> when to use T: ?Sized and when T: Sized ?
	* solenodic has quit (Ping timeout: 121 seconds)
	<delma> trait that says that type has staticly known size
	<iamrohit7> are objects in Rc allocated in the heap too?
	<dinfuehr> Arnavion: yeah that's true, I will try to implement it this way
	<Moonlightning> iamrohit7: yes--they have to be.
	<Moonlightning> iamrohit7: they can't be allocated on any one stack frame, because there might be other `Rc`s elsewhere keeping the value alive
	* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
	<Moonlightning> nathanael: genericized types get dropped just like non-genericized types!
	<iamrohit7> Moonlightning: delma: thanks for the help.
	<Moonlightning> You're welcome, iamrohit7. :)
	* lucian (lucian@moz-7hsb6f.cable.virginm.net) has joined
	* sp3d has quit (Connection closed)
	* rschiffl1n has quit (Ping timeout: 121 seconds)
	<Moonlightning> nathanael: also, those're references--pointers exist in Rust, and are /very/ different things.
	<iamrohit7> Moonlightning: last question, clone on an Rc increments the counter?
	* ideasman42 (cambo@moz-hf4pn0.iinet.net.au) has joined
	<delma> yeah
	<delma> and Drop implementation decrements
	* ygrek has quit (Ping timeout: 121 seconds)
	<iamrohit7> delma: Drop is manually implemented for it?
	* foser___ has quit (Client exited)
	<Moonlightning> iamrohit7: you may want to check out the documentation for Rc ( https://doc.rust-lang.org/std/rc/ )
	<iamrohit7> Moonlightning: yeah, sure.
	<phaazon> iamrohit7: I think automatic Drop impl doesn’t have a sense
	<phaazon> but I might be mistaken
	<phaazon> any*
	* MikeIon (michael@moz-qm3.0ef.126.1.IP) has joined
	<nathanael> Moonlighting: *mut T is a reference?
	* futile (felix@moz-6ii5jc.dip0.t-ipconnect.de) has joined
	<phaazon> nathanael: a pointer
	* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
	* solenodic (solenodic@moz-o2k.dlj.109.66.IP) has joined
	<nathanael> Rust reasons about lifetimes for pointers?
	<Moonlightning> nathanael: pointers in Rust should be used very sparingly--they're `unsafe` and only really exist for low-level implementations and rare cases in which references don't suffice.
	<phaazon> nathanael: no
	<phaazon> pointers are unsafe
	<Moonlightning> nathanael: it doesn't; you have to do that yourself. That's one reason they're so `unsafe`!
	<phaazon> you cannot tag them with lifetimes
	* kerrick has quit (Ping timeout: 121 seconds)
	<nathanael> That's why I'm confused by the error message "the parameter type `T` may not live long enough" when T is only used as a pointer type.
	<phaazon> if you’re not doing something very very specific or tweaking performance for very low level code, you won’t need pointers
	<phaazon> nathanael: show the code
	<phaazon> that’s typically because you lack a constraint on your T type
	<nathanael> https://gist.github.com/nathanaeljones/80792ff3ffb5854f7a18ba40f60c6770
	* rschiffl1n has quit (Ping timeout: 121 seconds)
	<phaazon> yeah
	<phaazon> you box your T
	<phaazon> by default, a Box requires its parameter to live as long as your program
	<phaazon> you have to explain more about your problem
	<phaazon> to put the correct lifetime
	<phaazon> or
	<nathanael> So what's the best way to register callbacks that mutate their parameters
	<phaazon> in your where clause
	<phaazon> add T: 'static
	<phaazon> but I kinda discourage that and either put the correct lifetime in the box
	<phaazon> nathanael: that’s a very general problem, there’s no such thing as “the best way” :)
	* breadmenace^ has quit (Ping timeout: 121 seconds)
	<Moonlightning> fqtw: so how about those prev_power_of_two() usecases? I know I'd like to see it added
	* findow (Mibbit@moz-akf720.hsi3.kabel-badenwuerttemberg.de) has joined
	<fqtw> Moonlightning: im using next_power_of_two() and divide by two now
	<nathanael> I tried adding a lifetime in the box. Perhaps I'm misunderstanding the effect of adding + 'static
	<phaazon> nathanael: what lifetime did you add?
	<phaazon> Box<T> and Box<T + 'static> are exactly the same, just for you to know
	<phaazon> so if you use Box<T>, you need T: 'static
	<phaazon> though, if you have a better lifetime than that
	<phaazon> you can do Box<T + 'a> where T: 'a
	* mkraemer has quit (Quit: WeeChat 1.5)
	* J_Arcane (J_Arcane2.0@moz-ji1s4d.bb.dnainternet.fi) has joined
	<nathanael> So you can 'downgrade' from 'static to something more restrictive in a box?
	<Moonlightning> fqtw: note that next_power_of_two() returns self if self.is_power_of_two()
	<phaazon> yep
	<phaazon> that will tell for which lifetime the box is valid
	<phaazon> for instance:
	<fqtw> Moonlightning: yea but that doesnt happen because i partition() those away beforehand
	* mkraemer (mkraemer@moz-nodm6n.marius-kraemer.de) has joined
	<nathanael> (non-reduced code): https://gist.github.com/nathanaeljones/95a3a61d50620ee19190b69741dc7e8d
	<phaazon> struct Foo<'a, T> where T: 'a { box: Box<T + 'a> }
	<phaazon> that will restrict the Box to Foo
	<phaazon> if your Foo dies, the Box dies
	<phaazon> Box<Fn(*mut T, &[u8]) + 'a>
	<phaazon> and same for the other box
	<phaazon> though, why using pointers?
	* breadmenace (breadmenac@moz-99sjhj.sntcca.sbcglobal.net) has joined
	* Moonlightning wonders what's up with that point--yeah.
	<nathanael> What qualifies as 'static, though?
	<phaazon> anything that can live as long as your program
	<phaazon> Box allocates on the heap, so by default, and because it doesn’t have a lifetime, it cannot know which lifetime the inner value has
	<phaazon> so it’s 'static by default
	<nathanael> I.e, readonly data segment? Or something that Owned and has that potential, if stored somewhere static?
	<findow> Hi, I want to add a linker path to cargo. Up to now I just added env RUSTFLAGS="-L./", but when running `cargo help rustc` it suggests tohat I can use the build.rustfalgs option. But I couldn't get it working in cargo.toml. Does anybody know how to set this option?
	* futile has quit (Quit: WeeChat 1.6)
	* MikeIon has quit (Ping timeout: 121 seconds)
	* foser___ (foser@moz-g0ha5f.dynamic.ziggo.nl) has joined
	<phaazon> nathanael: 'static doesn’t give any information about mutability
	<nathanael> So, for example D in this instance is a cloneable owned type with no references. T is ephemeral and only created for the purpose of executing these functions. Each instance of T will outlive the function call, but no more. We're not capturing T.
	<phaazon> it’s just a lifetime
	<phaazon> pub fn invoke<'f,'b,'c,'d,'e>(&'f self, upon: &'b mut T, method: &'c str, json_request_body: &'d [u8]) -> Result<JsonResponseBuf>{
	<phaazon> I really wonder what you’re doing :D
	<phaazon> you should use lifetime ellision pal!
	<nathanael> I'm trying to do middleware helpers with closures, basically. A recent refactor made that eligible for elision :)
	* ur5us has quit (A TLS packet with unexpected length was received.)
	* ur5us (ur5us@moz-belaqk.ihug.co.nz) has joined
	* montanonic has quit (Ping timeout: 121 seconds)
	* descender has quit (Quit: ...)
	* vvv has quit (Ping timeout: 121 seconds)
	* jensnockert (jensnockert@moz-34v09j.corp.bahnhof.se) has joined
	* ur5us has quit (Ping timeout: 121 seconds)
	* Trangar has quit (Connection closed)
	* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
	* Philpax (Philpax@moz-5lrr6m.optusnet.com.au) has joined
	* arBmind has quit (Quit: Leaving.)
	* shellac (pldms@moz-lngnj4.bris.ac.uk) has joined
	* rschiffl1n has quit (Ping timeout: 121 seconds)
	* junqed (junqed@moz-6jq.3fb.70.178.IP) has joined
	* quasisphere has quit (Ping timeout: 121 seconds)
	<nathanael> So &'static and 'static have completely different meanings?
	* Morten (Morten@moz-9bcmlg.eduroam.uib.no) has joined
	* fqtw_ (me@moz-r6jb71.dyn.telefonica.de) has joined
	<Moonlightning> 'static is a lifetime. It means that the type is allowed to live for the entire lifetime of the program.
	<nathanael> Because this compiles and I have no idea why: https://gist.github.com/nathanaeljones/168db41ad358404e5c35828da1438afe
	<nathanael> Whereas &'static means it is required to live for the life of the program?
	<Moonlightning> Owned types are always 'static. Reference types must be borrowed from an owned type, and have strict restrictions on their lifetimes.
	* fqtw has quit (Ping timeout: 121 seconds)
	<nathanael> Can "Owned types are always 'static." go somewhere prominent?
	* MikeIon (michael@moz-cp5m5a.dodo.net.au) has joined
	* Trangar (Trangar@moz-j8f.r0d.78.77.IP) has joined
	<Moonlightning> Heheh, yeah. I only learned that recently.
	* Morten has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
	<nathanael> Like page 1 would be nice.
	<Moonlightning> The `&` sigil is a little confusing, because other stuff--like the `mut` keyword and a lifetime--can go /after/ it, but before the underlying type name.
	<nathanael> Thank you for opening a new world for me. I've been struggling with this for months.
	<Moonlightning> &T has a lifetime; it's just elided. It /might/ be &'static T; it might be something else.
	<nathanael> And 'a,'b,'c,'d,'e,'f,'g,'h,'i,'j,'k ing myself to death.
	<Moonlightning> Er...double-check that. >.>
	* junqed has quit (Ping timeout: 121 seconds)
	<nathanael> Only within a function, right? At signature boundaries elision of lifetimes to the lowest expectation means the potential of the lifetime is unrecoverable, right?
	<Moonlightning> nathanael: You often don't have to specify the lifetime. See the Book's bit on elision.
	* kamil has quit (Quit: Leaving...)
	* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
	<nathanael> I know the rules for elision. I didn't grasp that Owned implied 'static. Everything hinted the opposite, or that Owned had a special lifetime category orthogonal to lifetime bounds.
	<Moonlightning> Uh...
	* montanonic (nicholas@moz-u3evs7.or.comcast.net) has joined
	<Moonlightning> Oh, /owned/ wasn't an identifier there; by it, I only meant...not behind a reference (or pointer, I guess)
	<Moonlightning> y'know..owned. XD
	* mib_8lfkui (Mibbit@moz-p4b.j64.37.103.IP) has joined
	* mib_8lfkui has quit (Quit: http://www.mibbit.com ajax IRC Client)
	* chris_99 (chris_99@moz-lel5jk.ir6t.2uic.04f8.2a01.IP) has joined
	<skade> How does Owned imply static? If I own something that has &'a references, it cannot be static?
	* rschiffl1n has quit (Ping timeout: 121 seconds)
	* safwan (uid93576@moz-va2btc.charlton.irccloud.com) has joined
	<Moonlightning> skade: all owned types are 'static, but not all 'static types are owned.
	* solenodic has quit (Ping timeout: 121 seconds)
	<nathanael> I just deleted 2/3rds of the lifetime specifiers from my (sizeable) codebase via regex. And it compiles.
	<nathanael> With two strategic insertions of 'static
	<skade> Box<Iterator<Item=Foo>> over &'a [Foo] is definitely owned, but has 'a as a lifetime
	* rubdos has quit (Ping timeout: 121 seconds)
	* jensnockert has quit (Connection closed)
	<skade> (Which is the most common case I can think of, where you need to override the standard lifetime of a Box)
	<ubsan> skade: I had not thought of that
	<ubsan> gg
	* tormoz has quit (Connection closed)
	* jensnockert (jensnockert@moz-34v09j.corp.bahnhof.se) has joined
	<ubsan> skade: Box<&'a Foo> also works
	<skade> right, though that's a bit odd :D
	<ubsan> just a bit :P
	* tormoz (geov@moz-3q6.afp.124.178.IP) has joined
	<Moonlightning> So, wait, that makes the Box not `'static`?
	<ubsan> yeah
	<ubsan> it's 'a
	<skade> sure, if it were static, it could outlive the collection
	<skade> i'll write you an example
	<Moonlightning> Okay, I buy it.
	<skade> (but you need the box, due to dynamic dispatch)
	<Moonlightning> I generalized that too much.
	<Moonlightning> Someone said `String`s are always 'static...which is true, because you can't stuff a reference into a String >.>
	<skade> The notiation in that case is `Box<Iterator<Item=Foo>> + 'a`
	* rschiffl1n (randy@moz-g559e7.9f9c.64c2.8801.2600.IP) has joined
	* thvdburgt (thvdburgt@moz-pgac4k.direct-adsl.nl) has joined
	<Moonlightning> So, instead..."anything that doesn't have an explicit or inferred lifetime parameter is 'static"?
	* khades has quit (Connection closed)
	* seu has quit (Quit: No Ping reply in 180 seconds.)
	* kamil (kamil@moz-d3c3p3.play-internet.pl) has joined
	* Trangar has quit (Quit: Leaving)
	* seu (quassel@moz-eg8m2t.re) has joined
	<Moonlightning> /ping nathanael. Sorry. >.<;
	<nathanael> Moonlightning: Do not apologize - this has been the most enlightening conversation on IRC for me.
	<Moonlightning> Heh :P
	* rschiffl1n has quit (Ping timeout: 121 seconds)
	<Moonlightning> owned does not, in fact, imply 'static
	<Moonlightning> but 'static is also not only for references. Which is kinda counterintuitive.
	<Moonlightning> So, I guess...if a type's lifetime is not restricted because it was borrowed, then its lifetime is 'static.
	* SuperFluffy (janis@moz-2gk4sp.customers.d1-online.com) has joined
	* rkruppe (chatzilla@moz-o3kq3g.p5eo.1gvm.41b8.2001.IP) has joined
	<nathanael> That's a superset of Owned without lifetime specifiers.
	* frankpf (frankpf@moz-npu.red.162.150.IP) has joined
	* frankpf_ (frankpf@moz-npu.red.162.150.IP) has joined
	<nathanael> I think a table of examples with effective lifetime annotations would help the Book a lot.
	* [steveklabnik] is away (catch you later)
	* Ping reply from steveklabnik: 1.08 second(s)
	<Moonlightning> Should maybe open an issue for that
	<nathanael> I'll save this chat log and put it on my insanely long todo list.