Generic const - a non-functional view

[Steven Schveighoffer]

"Walter Bright" wrote
> D has a minimal system that is effective - const and invariant. The fact 
> that it still seems to cause such misunderstanding is enough evidence for 
> me to be very, very wary of adding more complexity to it.

Effective only for a feature that doesn't exist yet (pure functions).

>From my experience, the D const system as it stands now does not cause such 
misunderstanding.  Everything is quite clear.  What seems to cause some 
misunderstanding:

- Why all string library functions require invariant arguments (probably #1 
complaint on NG for newbies trying out D2)
- The concept of tail-const pointers and arrays
- Why you cannot have tail-const class references
- Why you cannot have logical const structures.

Explaining const and invariant by itself is easy.  And understandable.  It's 
the usages of them which are confusing.

But I look at this extension as a sort of 'meta' const.  It's like templates 
and mixins.  Some people (not me!) can do magic with these that would not be 
possible if templates weren't so wonderfully complex.  But to use a template 
that someone wrote isn't even close to as difficult.  For example, the 
conversion template to(T).  To use it I just do:

auto str = to!(string)(5);

and I don't have to know how or why it works.

Similarly, if a library implements const groups such as lconst like:

const alias mutable;
alias const!(~mutable) lconst;
alias invariant!(~mutable) linvariant;

One does not have to understand exactly what they mean.  All they have to 
know is 'declare a member mutable if you want it to be mutable when the 
class is lconst or linvariant.'  This kind of thing is easy to document and 
explain.  One does not HAVE to know all the details of how these magic 
generic const structures work, all they have to know is how to use them.  In 
fact, they do not need to know much more than what they already must learn 
for the current const.  Except that the last two points of confusion I 
identified above are removed.

In any case, like I said, if you find that it would be difficult to 
implement in the compiler, then so be it.  But assuming that you can't add a 
feature because it would complicate the language, in light of the fact that 
you already complicated the language too much, seems to be a contradictory 
argument.  We already have a complicated language by your measure.  Why not 
make it a complete language?

-Steve