The problem with 'const'/'immutable' -- what is the _plan_ for fixing this (if we had infinite time to implement it)?

[Gor Gyolchanyan]

These problems come from the fact, that any data can be seen as either
mutable, immutable or divisible.
The problem of head-const comes from the fact, that reference types
should be divisible (the reference and the object) each division of
which should have its own mutability.
The urge to have both of them immutable is completely sensible,
because it gives strong purity guarantees for functions.
The problems is that the guarantee it gives is not always necessary.
It should be enforced when it is needed, but nowhere else.

On Thu, Dec 29, 2011 at 7:04 PM, Mehrdad <wfunction at hotmail.com> wrote:
> From what I've seen, it looks like we're putting lots of bandages on
> const/immutable without actually having a fundamental solution to the
> problem moving forward.
> i.e. we're fixing each individual problem, but not the fundamental issue.
>
> Const/immutable have the following properties:
>
> a. 'immutable' must be transitive.
> b. immutable and mutable data must both implicitly convert to 'const'.
> c. D wants purity to be possible, which requires transitive const.
> d. There is no such thing as a 'read-only' (i.e. head-const) variable.
> e. Reference types and value types are treated similarly syntactically,
> making them almost indistinguishable.
>
> ... which cause the following *_inherent_* (IMHO) problems:
>
> 1. The address of a const(T) variable is necessarily a const(T)*, which
> implies that the variable MUST have been read-only -- even if it was a
> reference type.
> 2. This makes const references non-rebindable. (Rebindable(T) has been
> introduced to solve this issue, but it's hard to type/use, and so few people
> actually use it.)
> 3. This means having a read-only reference to something mutable is
> impossible.
> 4. This makes various data structures, e.g. const ranges, to be virtually
> unusable (or, if possible, a pain in the rear to use) -- especially when
> they are reference types and especially when dealing with pure functions.
>
> Given that D does *not* plan to support head-const or tail-const, and given
> that a detailed plan is the most important thing (otherwise there isn't a
> goal to look forward to), I guess the question is:
>
> _What is the current plan (in *detail*) for fixing these problems?_



-- 
Bye,
Gor Gyolchanyan.