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 ([email protected]) 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 ([email protected]) 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 ([email protected]) 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 ([email protected]) has joined
<nathanael> Moonlighting: *mut T is a reference? 
* futile ([email protected]) has joined
<phaazon> nathanael: a pointer
* rschiffl1n ([email protected]) has joined
* solenodic ([email protected]) 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 ([email protected]) 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 ([email protected]) 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 ([email protected]) 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 ([email protected]) 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___ ([email protected]) 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 ([email protected]) has joined
* montanonic has quit (Ping timeout: 121 seconds)
* descender has quit (Quit: ...)
* vvv has quit (Ping timeout: 121 seconds)
* jensnockert ([email protected]) has joined
* ur5us has quit (Ping timeout: 121 seconds)
* Trangar has quit (Connection closed)
* rschiffl1n ([email protected]) has joined
* Philpax ([email protected]) has joined
* arBmind has quit (Quit: Leaving.)
* shellac ([email protected]) has joined
* rschiffl1n has quit (Ping timeout: 121 seconds)
* junqed ([email protected]) has joined
* quasisphere has quit (Ping timeout: 121 seconds)
<nathanael> So &'static and 'static have completely different meanings?
* Morten ([email protected]) has joined
* fqtw_ ([email protected]) 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 ([email protected]) has joined
* Trangar ([email protected]) 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 ([email protected]) 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 ([email protected]) 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 ([email protected]) has joined
* mib_8lfkui has quit (Quit: http://www.mibbit.com ajax IRC Client)
* chris_99 ([email protected]) 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 ([email protected]) 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 ([email protected]) has joined
<ubsan> skade: Box<&'a Foo> also works
<skade> right, though that's a bit odd :D
<ubsan> just a bit :P
* tormoz ([email protected]) 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 ([email protected]) has joined
* thvdburgt ([email protected]) 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 ([email protected]) has joined
* Trangar has quit (Quit: Leaving)
* seu ([email protected]) 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 ([email protected]) has joined
* rkruppe ([email protected]) has joined
<nathanael> That's a superset of Owned without lifetime specifiers. 
* frankpf ([email protected]) has joined
* frankpf_ ([email protected]) 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.

https://www.blackl.net/lifetime-static.txt