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

Mehrdad wfunction at hotmail.com
Thu Dec 29 07:04:19 PST 2011


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


More information about the Digitalmars-d mailing list