Const sucks

[Oskar Linde]

Walter Bright wrote:
> Const, final, invariant, head const, tail const, it's grown into a 
> monster. It tries to cover all the bases, but in doing so is simply not 
> understandable.


I have not really been following the discussions thus far, but would 
still like to offer my uninformed view on things. (More questions than 
opinions actually)


1. I think one reason it is not understandable is the poor choice of 
keywords. My latest reiteration on the keywords (elsewhere in this thread):

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58135

(This may sound like a silly issue, but the advantages to using 
descriptive names should not be underestimated. Imagine using 
banana/apple/orange instead of int/float/void.)


2. There are two distinct problems. Access control vs constantness of 
data. The old proposal doesn't really take advantage of that distinction.


3. For write access control, I don't see transitivity making as much 
sense. There are cases where you want write access to a certain depth. 
Certain members of a class need not be part of that class, and therefore 
not bound by the same non-mutability requirements. Robert Fraser has 
posted a few use cases too.

What are the motivations for transitivity here? What problems does it 
solve? Are there alternative solutions to those problems?


4. Transitivity could still make sense for constant data (there are few 
cases were it makes sense to have for example a compile time rommable 
pointer pointing to mutable data).


An alternative suggestion would be to make a better separation between 
constness and access control by making const intransitive and only 
referring to access control, i.e const would prevent modification access 
to data in the following forms.

- writing though a pointer
- modifying class fields
- calling non-readonly methods on classes
- changing element of an array
- appending to an array

This means, more or less the D 2.000 const but without transitivity, 
coupled with the recently suggested invariant proposal.

Combine this with my wish to rename invariant->const, const->readonly:

* readonly handle to access control
* const refers to constness of the actual data
* readonly would be intransitive
* const would remain transitive

data -- const -- transitive
access -- readonly -- intransitive

simple, right? :)

The behavior of readonly would become (all of this should be deducible, 
so just skip this part):

A readonly type prevents modifying access through that type.

readonly int *  a; // no writing allowed through a
readonly int    b; // readonly doesn't apply to non-reference types
readonly Class  c; // c can be reassigned but is a readonly reference
readonly Struct d; // members are readonly, d isn't
readonly int[]  e; // e may change, e[] may not

Structs are value types, so readonly doesn't apply to them. It does 
however apply it its members.

struct S { int[] arr; String str; }

readonly S s;

Here, s.arr and s.str are readonly.

This means that as far as readonly is concerned, a struct containing a 
reference to data behaves the same as a free reference to data.

For arrays:

readonly Class[]           g; // readonly array of mutable classes
readonly(Class)[]          h; // mutable array of readonly classes
readonly readonly(Class)[] i; // readonly array of readonly classes

TransitiveReadonly!() is possible to implement.

references to constant data are automatically readonly.

const(int)[]  j; // j is readonly

Intransitivity allows all combinations of mutability [m] and 
immutability [i] for nested types:

[m][m][m] int[][][]
[i][m][m] readonly int[][][]
[m][i][m] readonly(int[][])[]
[m][m][i] readonly(int[])[][]
[i][i][m] readonly(readonly(int[][]))[]
[m][i][i] readonly(readonly(int[])[])[]
[i][m][i] readonly readonly(int[])[][]
[i][i][i] readonly(readonly(readonly(int[]))[])[]

As far as I can see this resolves the issues with head/tail const and 
the issues with class references in the latest proposal. But I have 
probably missed many issues.

-- 
Oskar