Polonius: Either Borrower or Lender Be, but Responsibly - Niko Matsakis

Rust 2018 brought with it “non-lexical lifetimes” (NLL), a big overhaul of how the borrow checker worked that allowed it to accept a lot more programs. And yet, we’re still not accepting the full range of programs that was envisioned by the original NLL RFC - this is both for performance reasons and because the formulation didn’t turn out to be as flexible as originally thought.
Polonius is a “reframing” of Rust’s borrow checker. It works quite differently than the original system. Rather than tracking how long each reference is used (its “lifetime”), it tracks where each reference may have come from (its “origin”) - and it does so in a very fine-grained way. As a result, Polonius is able to accept all the programs that the NLL RFC envisioned, and a few more! We also believe it can be made more performant (though that has yet to be fully proven out).
This talk will explain how Polonius works in a simple and example-driven style. It will help you to gain a deeper understanding of how Rust’s borrow checker works internally.
---
Note from the conference: The slides for this talk were not captured and we've re-recorded them after the fact. Some of the visuals did not work perfectly, and for that we apologize.

[@maximus1172]

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 !!

[@smth_witty]

1:15 That was a great moment of comedic timing and a great save/joke by Niko

[@isaiahdante7362]

I realize I'm kind of off topic but do anybody know a good site to stream new tv shows online ?

[@nikolasbrendan7928]

@Krew Abdiel Yup, I've been watching on Flixzone for since march myself :)

[@maximussamir2332]

@Krew Abdiel thank you, I signed up and it seems like a nice service :D Appreciate it !!

[@gatlinthatcher7651]

@Isaiah Dante you are welcome =)

[@j3kfd9j]

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?

[@edgeeffect]

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.

[@jeffg4686]

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

[@blackwhattack]

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

[@jeffg4686]

@@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)...

[@blackwhattack]

@@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.

[@jeffg4686]

@@blackwhattack - thanks

[@porky1118]

Will this solve this problem:
- case that doesn't work:
object.call(object.value());
- case that works:
let value = object.value();
object.call(value);

[@ZiggyGrok]

The question I had that wasn't answered: what prevents this from being the way we do borrow checking today?

[@shekhinah5985]

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".

[@christopherprobst-ranly6284]

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.

[@protowalker]

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.

[@christopherprobst-ranly6284]

@@protowalker Sounds interesting. Any intel on when this will land?

[@blackwhattack]

@@christopherprobst-ranly6284 check out the zulip chat, Niko and others said they will try to dedicate more time to this starting 2021!

[@shekhinah5985]

No