[HN Gopher] The borrow checker within
___________________________________________________________________
The borrow checker within
Author : yurivish
Score : 45 points
Date : 2024-06-12 13:00 UTC (2 days ago)
(HTM) web link (smallcultfollowing.com)
(TXT) w3m dump (smallcultfollowing.com)
| yuvadam wrote:
| I really enjoyed this post, resonates with many small experiences
| I had learning the various patterns that do and don't work in
| Rust.
|
| Also blows my mind how crazy complex these language design topics
| are.
| Animats wrote:
| Good to see this.
|
| _" There is another theme running through here: moving the
| borrow checker analysis out from the compiler's mind and into
| types that can be expressed. Right now, all types always
| represent fully initialized, unborrowed values. There is no way
| to express a type that captures the state of being in the midst
| of iterating over something or having moved one or two fields but
| not all of them. These changes address that gap."_
|
| I have some misgivings about trying to do everything with types.
| That leads to having to perform complex, hard to understand
| operations on types, as you add and remove restrictions. Keeping
| borrowing orthogonal from types may be clearer. Not sure about
| this, though.
|
| I'd like to see back references addressed, so structs can have
| references to their owners. General concept: when possible, do
| statically what Rc, Weak, and .borrow() can do for backlinks at
| run time. Such static analysis seems possible for non-mutable
| references. Mutable is going to be tough, though. It's a lot like
| compile-time single-lock deadlock detection, where you try to
| check that the same lock is never locked twice in nested
| contexts.
| Georgelemental wrote:
| Previously: https://news.ycombinator.com/item?id=40553643
___________________________________________________________________
(page generated 2024-06-14 23:00 UTC)