On 9 January 2015 at 19:55, Keean Schupke <[email protected]> wrote: >> They do need to be part of the type system because their misuse leads >> to unsoundness, but requiring that different classifications of >> mutability be distinct types seems to lead to awkwardness when you're >> just trying to implement something with reasonable variance over >> mutability. > > > Surely you just need a 'const' type as in C++, and if you cannot cast away > const (you can only cast to const) it seems safe.
We (probably) want to support both mutability (weather the value can change) and writability (weather we can change the value, annotated 'read-only' here), as well as how this transitively affects usage of fields. In any case, the limits of variance tend to look like edge cases until you actually hit them yourself. See, even map looks odd in this situation. I should be able to map a function over a list with read-only elements, and have the result be mutable. The type system must be able to check (and hopefully, in the case of something as trivial as map, infer) each of the mutability invariants required. And yet I don't think I should have to describe this when I write a function like map. It's not that we don't know what the subtyping relationships are (although we did get them wrong initially), it's that the cognitive burden of having to maintain them as part of the types of values is unneccesary. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
