On 2/8/12 9:40 AM, Graydon Hoare wrote:
I understand you've developed strong thoughts about this, as has pcwalton, and suspect it results from a lot of high-bandwidth, in-person conversations in mountain view. I respectfully ask you to move *slowly* and at a somewhat laborious, tedious-to-you pace on the topic, for the "remoties" (marijn and myself). We've not been party to *any* of the in-person whiteboarding or conversing that leads to this conclusion, so the "to my mind ... only two options" statements come off as very immediate, certain and restrictive.
I'm sorry if I came across as wanting to shut off debate. That wasn't my intention. I woke up quite early today to take care of my daughter's teething episode so I am feeling a bit grouchy. Perhaps that's coming through.
If you look at what I wrote, the "second option" was basically "do something else." That is, I think there is a fairly wide set of solutions to address this problem. I happen to think the one I proposed is the closest to what we have today and something which may in fact be necessary for other use cases. But basically I think whatever we choose ought to enable the compiler and user to identify immutable memory with as little context as possible, as it is very useful for optimization and correctness (as illustrated by the Dan's bug problem).
Just limiting variance still presents a murky story, where given a reference to an instance of type T you don't really know whether its fields are immutable or not. I suppose you would have to think of the lack of a "mutable" declaration as "potentially immutable"; in the context of an @T or ~T pointer, those fields would truly be immutable. I'm not sure whether having field-level mutability is the best fit in that case, maybe mutability modifiers in types would be better (`mut T` etc).
Niko _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
