On 2/8/12 8:48 AM, Marijn Haverbeke wrote:
C++ has the same restriction. In practice I've found that it rarely comes
up.
Obviously, since const field are rare in C. In Rust, one rarely uses a
record type that doesn't have immutable fields.
The question, I guess, is how often we reassign an entire record at a
time. But, as pcwalton said, this is a type hole, so I don't think it's
a question of whether we fix it, it's a question of how. To my mind,
there are two viable options:
1. Introduce a distinction between assignable and non-assignable types,
as I proposed. This may mean that sometimes you have to use a boxed
type where you could otherwise use an interior type, because the type is
defined with immutable fields and you wish to mutate them (this is,
after all, what you would be doing in Java, O'Caml, or most other
languages). I don't view box allocation as a penalty: it's probably
going to be the default much of the time. To my mind, interior types
are the "bonus", great when they work but not always an option. That's
certainly how I've found it to be in C and C++ and I would expect no
different in Rust.
2. Remove the concept of mutable and immutable fields and replace it
with something else. I can think of various options but I chose option
#1 because it's going to be a smaller delta on what we have. Also, the
same concept (assignable types) is required if we move to types of
dynamic size (e.g., fixed-length arrays or records containing inline
arrays of unknown size). Still, maybe we want to discuss other ways of
controlling mutability besides the current approach... I certainly don't
feel wedded to what I proposed. I just want to be able to statically
tell if a given memory location is mutable or not.
In principle, as I wrote before, we could patch up the big hole by being
more restrictive about variance. There may be other holes. But frankly I
feel pretty strongly that if a field is declared immutable, it ought to
mean that no matter how many times you read that memory location, you
get the same result. This property would not be preserved in such a
system and I think that's undesirable. It's also true that getting rid
of field variance is itself rather ham-fisted and will lead to numerous
unnecessary type errors, though perhaps improved inference might help.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
