[rust-dev] Vectors, mutability & vec::dedup

Niko Matsakis niko at alum.mit.edu
Thu Dec 20 06:02:36 PST 2012

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 };


     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.


More information about the Rust-dev mailing list