• Mehrdad (28/28) Dec 29 2011 From what I've seen, it looks like we're putting lots of bandages on
• Gor Gyolchanyan (13/40) Dec 29 2011 These problems come from the fact, that any data can be seen as either
• Jakob Ovrum (10/16) Dec 29 2011 Tail-const works for everything but classes, and for them, this

Mehrdad <wfunction hotmail.com> writes:

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

Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:

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.

"Jakob Ovrum" <jakobovrum gmail.com> writes:

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.