3 ms·
> The issues the author highlights can be annoying, a smarter borrow checker could maybe solve them I don't think a smarter borrow checker could solve most of
by creata 1y ago
> The issues the author highlights can be annoying, a smarter borrow checker could maybe solve them
I don't think a smarter borrow checker could solve most of the issues the author raises. The author wants borrow checking to be an interprocedural analysis, but it isn't one by design. Everything the borrow checker knows about a function is in its signature.
- estebank 1y agoMaking partial borrows to be expressable in method definitions would allow the design pattern to be expressed without breaking the current lifetime evaluation boundary. Allowing the borrow checker to peek inside of the body of local methods for the purposes of identifying partial borrows would fundamentally break the locality of the borrow checker, but I think that as long as that analysis is only extended to methods on the local trait impl, it could be done without too much fanfare. These two things would be relaxations of the borrow checker rules, making it smarter, if you will.
- deleted 1y ago[deleted]
- ameliaquining 1y agoFixing the get_default example wouldn't require interprocedural analysis. (It requires Polonius, which, yeah, has taken a long time to ship.)
- estebank 1y agoThe get_default example requires only one to use the stdlib API: https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html#method.or_default https://doc.rust-lang.org/std/collections/hash_map/enum.Entr...