4 ms·

This is about moving rust's borrow checker into the type system. I don't follow the details (not a rust dev) but the top level plan of doing static checks in th

This is about moving rust's borrow checker into the type system. I don't follow the details (not a rust dev) but the top level plan of doing static checks in the static type system sounds right. Has interesting links to related projects.

eslaught 3y ago
There's more going on here. They are adding a notion of "places" (what I would call "field paths") and an explicit syntax for "modes" (what I would call "privileges"). So you can now say: shared(x.a.b.c) or: mut(y.d.e.f) That makes it possible to pass around a reference with the promise that the callee will only access a subset of the fields of whatever referenced type you're talking about, as well as other things. Superficially it looks very much like what I did in Regent [1] though I am sure the details differ widely. [1]: https://regent-lang.org/tutorial/06_privileges/ https://regent-lang.org/tutorial/06_privileges/
- cwzwarich 3y ago
  The Rust borrow checker has had this model for over a decade at this point; it's just not exposed as part of the language. One strong principle in Rust language design is to avoid proliferation of too many distinct reference types. In this case, I personally wish the language had support for it, since it would allow you to seamlessly refactor a piece of code into its own function.
  - pornel 3y ago
    The article mentions expanding capabilities to support self-referential structs. Currently structs are allowed to borrow from any data outside of them, but not from any of their own fields. Rust doesn't want to have move constructors, and borrowing from inline fields can't be safe, but borrowing from heap-allocated data owned by the same struct should be possible, and currently there's no non-hacky way to express that.
    - cwzwarich 3y ago
      I was specifically referring to the ability to borrow a set of fields/paths. Enabling more useful self-referential structs would be something more novel.
- fanf2 3y ago
  “Place” has long been Rust’s term for lvalue https://doc.rust-lang.org/stable/reference/expressions.html#place-expressions-and-value-expressions https://doc.rust-lang.org/stable/reference/expressions.html#...

eslaught 3y ago

There's more going on here. They are adding a notion of "places" (what I would call "field paths") and an explicit syntax for "modes" (what I would call "privileges"). So you can now say: shared(x.a.b.c) or: mut(y.d.e.f) That makes it possible to pass around a reference with the promise that the callee will only access a subset of the fields of whatever referenced type you're talking about, as well as other things. Superficially it looks very much like what I did in Regent [1] though I am sure the details differ widely. [1]: https://regent-lang.org/tutorial/06_privileges/ https://regent-lang.org/tutorial/06_privileges/

cwzwarich 3y ago
The Rust borrow checker has had this model for over a decade at this point; it's just not exposed as part of the language. One strong principle in Rust language design is to avoid proliferation of too many distinct reference types. In this case, I personally wish the language had support for it, since it would allow you to seamlessly refactor a piece of code into its own function.
- pornel 3y ago
  The article mentions expanding capabilities to support self-referential structs. Currently structs are allowed to borrow from any data outside of them, but not from any of their own fields. Rust doesn't want to have move constructors, and borrowing from inline fields can't be safe, but borrowing from heap-allocated data owned by the same struct should be possible, and currently there's no non-hacky way to express that.
  - cwzwarich 3y ago
    I was specifically referring to the ability to borrow a set of fields/paths. Enabling more useful self-referential structs would be something more novel.
fanf2 3y ago
“Place” has long been Rust’s term for lvalue https://doc.rust-lang.org/stable/reference/expressions.html#place-expressions-and-value-expressions https://doc.rust-lang.org/stable/reference/expressions.html#...