This (Patrick's Jun 4 description) seems extremely promising. It'll
make aliases slightly less powerful than they currently are, but the
rules are very simple and predictable — which, in my opinion, is more
attractive than having something as powerful as possible at the cost
of extreme user confusion.
It seems only the 'two aliases may not alias each other' rule requires
alias analysis. I think we could formulate that instead as having the
"can't touch any variable that roots an alias rule" also apply to
mutable aliases passed to functions, so that you can't pass something
by mutable alias that you're passing by alias, we don't need serious
alias analysis at all (and maybe that's what you were suggesting).
Another implication is that any field reachable from a local root by
an immutable path can also be safely aliased, as the root anchors it.
Maybe even paths with mutable elements but no boxes or tags are safe
-- they can be mutated, but not in a way that invalidates the alias.
Also, it seems that immutable 'alias rooting' variables can safely be
read, just not written.
We'll have to see how much inconvenience this produces for alts. I had
already ran into the unsafety you described when trying to iterate
over a list by repeatedly setting the list variable to the tail in an
alt case. Maybe having a copying variant of alt ('alt copy (x) { ...
}'?) for convenience will be needed.
I'll try to start implementing a checking pass for this, and probably
follow up later today.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
