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