(forwarded to list on request)
On 09/02/2012 12:53 AM, Alex Burr wrote:
FWIW,the issue of mutability was discussed a lot on the bitc-dev mailing
list.
A particularly troubling case was if you have a struct foo which is
marked immutable, which
contains a field bar which is not, what happens if you take a reference
to bar and pass it
to a function F?
The type of F doesn't know anything about foo, so F could potentially
mutate it.
I don't know enough about rust to see if you have this problem.
Yeah. That's more or less what we're talking about here. We have an
existing sort of approach to this that, sadly, has a soundness hole in
it due to its subtyping rules. My initial hope is that maybe we can fix
the subtyping rules. But others are, I think, proposing we keep the
subtyping rules as they are and adopt a secondary definition similar to
what C++ does, differentiating "assignability" from non. Possibly buying
us some more wiggle room in (or even freedom-from-needing) our
safe-reference checker. And possibly (?) working better with some other
future work (regions, interior vectors).
I don't actually know how C++ goes about deriving and propagating that
assignability definition -- or whether it simply has to do with its
auto-generation of op= methods -- so have to look more into what it
means there before I can suitably comment. It might be similar to our
reference-checker's current synthetic concept of "immutably rooted"
values. It might wind up working well, not sure. There might be several
other approaches too; it's an old and quite general sort of problem.
Really I think the question hinges on intuitions about transitivity,
figuring out which is more counterintuitive:
- Something you mark as mutable that you find yourself restricted
from mutating due to its sub- or super-structure being immutable.
- Something marked as immutable that still manages to change
bits-in-memory due to part of its sub- or super-structure being
mutated.
Neither is really great. Depending on how you model things, the latter
may be a soundness hole (I had thought our safe-reference checker
prevented it, but apparently not). As with so many things in languages,
we're dancing around a tension between unpleasant results, looking for a
nice compromise, or at most a compelling reason why one or the other is
more-necessary.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
