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?_

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@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.

On Thursday, 29 December 2011 at 15:04:18 UTC, Mehrdad wrote:
> 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?_

Tail-const works for everything but classes, and for them, this proposal:

https://github.com/D-Programming-Language/dmd/pull/3

Seems to have been settled on. Walter's reply at least hints at this being planned for inclusion.

The proposed solution is better than Rebindable because std.concurrency can understand it correctly (Rebindable breaks the type system to do what it does), which seems to be important for Variant to be usable with std.concurrency.