View mode: basic / threaded / horizontal-split · Log in · Help
December 29, 2011
The problem with 'const'/'immutable' -- what is the _plan_ for fixing this (if we had infinite time to implement it)?
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?_
December 29, 2011
Re: The problem with 'const'/'immutable' -- what is the _plan_ for fixing this (if we had infinite time to implement it)?
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.
December 29, 2011
Re: The problem with 'const'/'immutable' -- what is the _plan_ for fixing this (if we had infinite time to implement it)?
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.
Top | Discussion index | About this forum | D home