On 2/8/2012 8:03 AM, Niko Matsakis wrote:
1. the type hole appears in the language as it is today, not some hypothetical future without alias analysis or with regions. It occurred to me that this might not be obvious.
Understood. Thankfully we do not have enterprise customers breathing down our necks for a hot patch just now, so we don't have to have a fix for it in by the end of the day. We can take our time to talk through the problem thoroughly.
2. Making fields invariant but still allowing assignments that overwrite immutable fields would indeed give weaker guarantees but not quite as weak as I implied. For example a type @T would be immutable as declared. It is only references where the declared mutability of fields would have a murky meaning (I think, anyway)
I agree these issues are murky! I don't mean to imply I have some equally-well-thought but opposite belief. Merely that taking our cues from C++ here might not work very well either: their subtyping-on-const rules are often bizarre and related to many matters we don't face, and they start with the assumption that everything-is-mutable, and they don't have safe-alias analysis ... I think it's useful to *look* at what they come up with, but we might well wind up someplace other than they did. It's also useful to look at cyclone, D, the MLs, and various other players in this space.
3. Regarding structural types, I shouldn't have dragged them into this. :) There are many ways to address the verbosity of mutable fields, of which nominal record types are but one.
Fair. I've only been carrying on with the term "structural" in response as a short hand for denoting "interior types composed of records, resources, tags, tuples, and scalars". But that seemed like a long noun-phrase. Perhaps "structured" is a better word :)
Hope that makes sense. I can clarify more when I am not typing on my phone. :)
Yeah. We'll talk more. -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
