Flesh out vigilant references
In the wiki is an article on my new and shiny™ vigilant references, but it is very informal up until now, there is still quite a bit missing.
-
Finish informal write-up -
Problem: What is with vectors? One reference could cause a reallocation and thus invalidate the other one. -
No, becausePin
prevents moves but requires raw pointers. Can vigilant references help?&vig
still have lifetimes but they couldn’t be named in aPin
because there is no'self
, and even that would not work (?) because a move would invalidate a reference but not end the lifetime. -
Compare withGhostCell
-
Why are &vig
better than pointers even without proof objects? -
Compare to ATS viewtypes/proof objects -
Tease refinement types
-
-
Some extra stuff: -
Write something on ownership, drop semantics, move semantics, clone and copy. -
We still need a mutability marker for function arguments in case of references that cross thread-bounds -
Snippet $46, optimizing code because of &mut
-
Lifetime extension à la Polonius the crab -
Add rationale for MPB: If we would reorder expressions, it would work. The compiler may already reorder as it sees fit. Why can’t we do it as well?
-
-
Define a formal syntax -
Define a formal semantics -
Remove the disclaimer when finished
Edited by Jasper Clemens Gräflich