[/Burrow/Borrow/ damn spellcheck]

More thoughts on this:

The syntax I used earlier (&'a NAME) has a potential problem that it would
make the pointer borrowed, rather then the pointee. I don't really
understand the rules of borrowed owned ptrs: can you write through them?
can others have live aliases? (If unique ptrs work internally like Rc<>s
then that' parts fine [~T -> &'a ~T -> &'a T], the latter by an automatic
.borrow()) -- but I'm not really interested in declaration syntax here.

By the way, are ~ptrs special to the borrow checker in any way other then
autoref/deref (By the looks of it DST will make slices not special to the
borrow checker and special @s were turned into non-special Rc's -- is the
same thing being done for ~s)?

Informal semantics:
  structs can have fields borrowed to a lifetime. That binds the lifetime
(if you use the same name twice you get an error).
If a field is borrowed to a lifetime:
  a) When constructing the struct, a borrowed value can be used as long as
you put all references into the right places in the new struct
  b) Dually, when destructing the struct, the parts end up borrowed in the
same relationship they were in the struct.
  c) It can only be accessed borrowed to that lifetime.
  d) It can't be set

The latter 2 behave in the same way as a borrowed unique pointer in a stack
frame -- you can say that this proposal makes stack frames less special by
allowing ordinary structs to root borrows. This has the disadvantage of
making lifetimes non-totally-ordered. Is that too bad?


--
Ariel Ben-Yehuda
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to