The problem with const proposals

[Sönke Ludwig]

Gregor Richards wrote:
> Not a single person on this board (and I mean NO ONE) has a grasp over 
> everything that one can reasonably expect const to do. What we need to 
> do is construct a complete list of features that the const system ought 
> to have, so that any const proposal can be checked against the "good 
> clean const fun" checklist. Instead, what we have is suggestion after 
> suggestion, each with good points but each with fundamental flaws. We're 
> never going to get anywhere like this because nobody knows what everyone 
> needs.
> 
> Disclaimer: It is of course impossible to make a list that makes 
> everyone happy. C'est la vie.
> 
>  - Gregor Richards

I think - functionally - most of the proposals so far would suffice. But it 
would sure be interesting to have a more or less representative coverage measure.
 From my personal experience with working on a fairly complex codebase (about 
500 modules/classes), which was first partially ported from C++ to non-const-D, 
before 2.0 was out and since then has got const/invariant brought in, my list 
would roughly be:

arrays:
const(T)[]
const(T[])
tailconst(C)[]
const(C[])
T[const(C)]
const(T)*[]

pointers:
const(T)*
const(T*)

inside structs/classes:
tailconst(C)
invariant T

(C=class, T=any)

The same goes for invariant.
This is from a quick grep over the code base including some workarounds for 
things which are currently impossible in that form. The more complex type 
constructs I've found are only used locally without const or are implicit like 
in "auto pointerToClassRef = key in assocarray;".
Other related things are some invariant classes and const/invariant member 
functions.
Also, in the beginning I occasionally missed non-transitive const, but that has 
not been a problem since then.