On Thu, Aug 8, 2013 at 5:05 PM, David Jeske <[email protected]> wrote:
> >> Note that in most cases, deep const is a lot less useful than you might >> think, and what we actually wanted was deep immutable. > > > I don't understand this, since deep-const is strictly a superset of > deep-immutable. > It feels that way, but the semantic consequences go further than type inclusion, so it's a deceptive intuition. Deep const is a constraint on * your* reference. deep immutable is a guarantee about *all* references. So all deep immutable references are necessarily deep const, but a deep const reference does not preclude mutation by somebody *else*. The catch is that "immutable" is a type, but it can't be inferred, and it involves a behavior contract that goes past what we normally mean by a type. All of which is OK. I'm just pointing out why supertype intuitions may lead you astray here. As you said, if there are only const references, then something is > immutable. > My primary interest is not immutability, but const API contracts without > the code and runtime overhead of making read-only proxy types and > implementations. (I want C# readonly to work for non-scalars) > OK. Deep-const at a formal parameter guarantees that the receiver cannot modify the [transitive] graph. Curiously, this means that a deep immutable thing can be used to initialize a deep const binding or formal paramater without violating deep immutability constraints. > I would accept a C/C++ like unenforced-const, as in "please don't edit > this because you're probably not supposed to. If I was wrong, you'll need > to cast it to explicitly tell the compiler to let you edit it".. > Better not to allow saying something that isn't true. Much of the point here is to support concurrency, and if the keyword isn't enforced you totally lose that aspect of it. I'll respond on the rest later. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
