Finally grasped the mechanical steps I need to pay attention to when dealing with the borrow checker in today's rust code!! This needs to be documented in the rust book the way it was explained here, the best explanation of borrow checker yet !!
This is quite a good talk but more conference speakers need to look to Benno Rice when it comes to taking questions.... they're good for the person asking the question but kinda dull for the rest of us.
Great talk, very informative. Thanks to everybody working on this---everything mentioned would provide real "quality of life" benefits deserving of gratitude. A question: in the definition of a live loan, I don't understand why the `z` loan requires the `y` loan to still be considered live. Can the compiler not prove that now that it has assigned a reference to a part of foo (by way of `y`) to `z`, it will not need to dereference `y` again?
Will this solve this problem: - case that doesn't work: object.call(object.value()); - case that works: let value = object.value(); object.call(value);
Great talk, knowing the below the surface happenings in rust is essential imo - I have a long ways to go .... I'd like to know why the * is needed in &*map (27:50) if anyone can explain. It's always little isms like this the give me hang ups with languages like c++ because there is so many of them. Like in C++, the whole **void (I mean I get what it is, but sure makes language messy for someone new to language that doesn't get the isms. In fact, that would make a great book. Rustisms
I think it's unnecesary to say `&*map`. Basically the function in which he used this had a reference, so actually `map` was a pointer, by typing `*map` he accessed the actual value of the variable, and then made another reference `&*map`. He did it to desugar what Rust actually does for you (this is written up somewhere in the Rust book), so I think in Rust `map` and `&*map` are equivalent (when map is a reference), and the second one is more accurate. Please correct me if I'm wrong. here's some info: doc.rust-lang.org/book/ch15-02-deref.html#treating-a-type-like-a-reference-by-implementing-the-deref-trait read the paragraph linked to and also the next one
@@blackwhattack - thanks, good explanation. So essentially, a copy of value, then reference to that new location - am I reading that correct? Avoids a borrow from original variable since it's a new one (guessing)...
@@jeffg4686 There is no copying with references. It's just glorified pointers with additional memory safety. Rust tries to be nice to you so you dont have to dereference an argument for a function such as `&map` and type `*map` everywhere you use it. When he wrote `&*map` he just tried to remove all the levels of abstractions (language sugar) that are supposed to make your life easier. Also in (idomatic) Rust there is no implicit copies (except for numbers for which copies have the same or even less overhead than references) so if there was a copy involved you would see it with .clone() or .copy(). I encourage you to read the Rust Book. It really breaks things up into small problems and slowly builds on top of the previous stuff.
it's expensive to type check. the current implementation in rustc can be very slow and memory expensive. you can use it with the nightly compiler and RUSTFLAGS="-Zpolonius".
I don't get the final statement... Are Rust lifetimes doomed to be replaced by ... something else? Just curious. the language is already complex enough to teach.
Your code will stay the same. How it gets interpreted will be slightly different, but in a way that will only remove restrictions and not add new ones.
