8 ms·
Upcoming changes to Rust's borrow checker
- seanhunter 3y agoAs someone who was a bit obsessed with Hamlet as a teen, it's hillarious that they named this Polonius. Polonius is Ophelia's father in the play, and they probably named it because of his famous line: Neither a borrower nor a lender be, For loan oft loses both itself and friend, And borrowing dulls the edge of husbandry. He's a tragic but somewhat foolish figure, prone to fretting and offering kind of annoyingly obvious advice of which the above is an example.
- coderedart 3y agoWhat does dulling the husbandry mean in this context?
- seanhunter 3y agoHe's giving the advice to his son who is about to go off to university. What he's saying is if you get accustomed to borrowing you will lose your ability to budget properly.
- cjbgkagh 3y agoManagement and conservation of resources
- speed_spread 3y agoShakespeare was advocating for RAII?
- paulddraper 3y agoLosing full control of your finances
- Yoric 3y agoYes, if you look at the Polonius repo, this quote is featured prominently :)
- drexlspivey 3y agoFunny that this comment was made by yet another Hamlet character
- deleted 3y ago[deleted]
- Yoric 3y agoAlas, poor me!
- garyrob 3y agoIt may be obvious, but it's still worth stating! I loaned $1000 to a friend in my 20's, and ended up losing both the friendship and the money (though one was not wholly causal of the other).
- FpUser 3y agoI believe this is type of BS pushed by people with the agenda. What kind of friend you are (talking about real friends, not drinking buddies) if you let your friend sink. My friend loaned me $3000 cash when I was at the vet and my dog needed an urgent surgery. And I paid him back and he did not loose money and we did not loose friendship. And later on when I started to make good money I sometimes loaned to friends. One could not pay me back but we did not loose friendship either as he simply had circumstances beyond his control. I just told him consider it a gift.
- lolinder 3y agoWhat sort of agenda do you imagine people have? That you had a good experience with a friendly loan doesn't discount the bad experiences of thousands of people who did lose their friendships. We've given money to friends on multiple occasions to pay for medical bills, groceries, and the like, but every time I've entered a reciprocal business arrangement with friends or family (be that a loan or a paid work arrangement), I've regretted it immensely.
- FpUser 3y agoEveryone's situation is different. The fact that you've regretted it means zilch for somebody else. Maybe it is you an the type of friends / family you have. I helped my daughter few times and did not think one second about it. No regrets. You can not and should not generalize a particular situation.
- vacuity 3y agoYou're also generalizing though. The point is that either outcome could happen and you should be mindful of that. If you specifically never have an issue like that, good for you! But other people have been burned, and it's not any more valid for you to dismiss their experience.
- rob74 3y agoThanks for the explanation! But if his advice is to completely forego borrowing and lending, it's a bit counterintuitive to use his name for the borrow checker? OTOH, the borrow checker can certainly be described as "prone to fretting and offering kind of annoyingly obvious advice", so maybe it's appropriate after all?
- vore 3y agoWe love ironic names :)
- bradleyjg 3y agoGiven the context, it’s always funny to see these things played straight—-to thine own self be true tattoos and the like.
- deleted 3y ago[deleted]
- rayiner 3y agoThis seems very hard for a programmer to reason about. It’s odd to do this sort of flow-sensitive analysis on the CFG for a language feature that affects whether code is accepted or rejected, instead of some optimization that’s transparent to the programmer.
- mibsl 3y agoThis is done so that the programmer doesn't have to reason about it. Polonius makes the compiler accept code that's obviously valid, but the current borrow checker isn't sophisticated enough to declare it as safe. I've bumped into this kind of problem when writing rust, at first it was hard to understand why the compiler doesn't accept my code.
- FpUser 3y agoThis kind of control would drive me up the wall. If I write code and my logic is wrong I appreciate compiler being able to tell me to sod off. Doing it when the logic is perfectly valid is a turn off.
- vacuity 3y agoThat's the draw of having a borrow checker, which is arguably the contributor to the biggest pain points of Rust. Everything is a tradeoff. Rust's "unsafe" blocks are also a tradeoff. To my understanding, Rice's theorem ensures that, for checking borrows, either all invalid programs and some valid programs are rejected, or all valid programs and some invalid programs are accepted. Given Rust's goal of overall safety, the conservative route (which rejects some valid programs) is favored.
- FpUser 3y ago>" the conservative route (which rejects some valid programs) is favored." I understand it and consider it very reasonable choice given the goals. Still no fun ;)
- hollerith 3y ago
- skywhopper 3y agoI’m curious how adding this layer of additional flow analysis will impact compilation times. The article sort of glosses over this risk with worrying phrases like “hopefully efficient enough” and “harder to do efficiently”. The scope of what’s still left to do and even undesigned also makes the goal of incorporating this into the 2024 edition seem quite optimistic.
- rob74 3y agoWell, if the doubtlessly complicated code needed to parse such uncommon borrowing scenarios is only called when such a scenario is found, then it should only affect compilation times for code using such scenarios (which is, I hope, uncommon)?
- wredue 3y agoI doubt it all that uncommon. Rust reject A LOT of perfectly valid ideas. Or, at least, it used to. Apparently this has been getting better. If you look around at lifetime recommendations, for a while they were so annoying that most people were saying “just force a copy and don’t use lifetimes”.
- pornel 3y agoThere's more nuance to "don’t use lifetimes". Novices typically don't understand the relationship between owning and borrowing, and try to use temporary references where they semantically don't belong (in Rust ownership can't be as ambiguous as in GC languages, and references can't be made out of thin air — they borrow from somewhere that must already be owned/stored somewhere). So often the advice is not "don't use lifetimes, because the borrow checker can't handle them", but rather "don't use lifetimes where an owned value is required" or "don't use lifetimes until you understand how ownership works".
- tedunangst 3y agoIf the scenarios were that uncommon, it wouldn't be worth fixing. And now that they're accepted, they will undoubtedly proliferate. This is the new common.
- lukebitts 3y agoI feel like we've been hearing about Polonius for years, the authors must be glad its finally here!
- j-pb 3y agoHappy to see progress on this front, but very disappointed that the Datalog based checker is not used. Declarative formulations of these problems are much easier to maintain, verify, and spec than a imperative (re)implementation.
- vacuity 3y agoI imagine the biggest issue is performance. I'm sure an as-declarative-as-possible approach would be favored if it didn't sacrifice that.
- j-pb 3y agoThe thing is though that a lot of these problems are NP-Hard, so you're often better of with a general problem solver that knows tricks how to optimise the search for the solution, than something hard-coded where it's impractical to do that kind of dynamic programming.
- vacuity 3y agoOn the other hand, there may be a greater gain in specializing the solver for the problem you're tackling. Besides, they can copy some of the algorithms.
- deleted 3y ago[deleted]
- vlovich123 3y agoWill this improve borrow checking to correctly understand member borrowing of a struct? Like: fn borrow_field1(&mut self) -> &Foo { &mut self.field1 } fn borrow_field2(&mut self) -> &Bar { &mut self.field2 } fn do_something(&mut self) { let field1 = self.borrow_field1(); let field2 = self.borrow_field2(); }
- afdbcreid 3y agoNo, this is unrelated work. But see https://smallcultfollowing.com/babysteps/blog/2021/11/05/view-types/ https://smallcultfollowing.com/babysteps/blog/2021/11/05/vie... (only thoughts, nothing concrete or proposal).
- vacuity 3y agoI believe not. The method signature indicates that each reference claims exclusive access to the struct, so it may even be backwards incompatible to add the new behavior without a syntax addition. I believe one of the proposals to this end is "view types".
- fleventynine 3y agoThis is the biggest pain-point of the language. We need a solution.
- galangalalgol 3y agoWhy is that even safe?
- fleventynine 3y agoIt can be safe if the language provides a mechanism to tell the compiler that borrow_field1() and borrow_field2() will never mutably borrow the same fields. This would be part of the public API of those functions, and compilation would fail if the implementations were changed to borrow the same fields.
- csomar 3y ago
- Georgelemental 3y agoThe `polonius-the-crab` crate [0] allows using some of these patterns on stable Rust. [0]: https://docs.rs/polonius-the-crab/latest/polonius_the_crab/index.html https://docs.rs/polonius-the-crab/latest/polonius_the_crab/i...
- camila45 3y ago[dead]