Graydon Hoare wrote:
The_observational_ difference, on an owned value (i.e. you're the only
person who can even see the vector in question) is really just that the
latter would do a bunch of allocation, copying and freeing, and wind up
pointing to a different place containing exactly the same result. From
the perspective of the surrounding code, if it's not actually paying
attention to pointer values, those two lines are identical.
There is one difference here that's been brought to my attention and is
worth pointing out (though I don't think it's a problem). If the
objects in question have a destructor, then:
x = X { f: x.f + 1 };
and
x.f += 1;
are observationally different, since the first one will run a destructor
but the second will not. I think the bottom line here is that if you
have destructors, you should probably use privacy to guard the values of
those fields that you do not want modified.
One change that one could imagine is adding some sort of qualifier for
fields that cannot be modified *directly*, so that the first assignment
would be legal but the second not. Note that we still could not say
that `f` is *immutable*, because it could still be mutated, but you
could call it "const" or something like that. I personally would prefer
to see how far we can get using privacy instead just to keep things
simple, but this remains a potentially useful addition. Declaring
fields that should not be changed after the object is constructed is
after all not uncommon.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
