Const sucks

[Sean Kelly]

Walter Bright wrote:
> 
> So, what we are left with is:
> 
> o  no more final

By this you meant that "final" in 2.0 would work exactly as in 1.0, correct?

> o  const and invariant now mean "fully const" and "fully invariant", 
> where fully means "head and tail combined":
> 
> const int x = 0;   // x is constant
> const int* p = &x;  // neither p nor *p can be changed
> const(int*) p = &x;  // neither p nor *p can be changed
> const(int)* p = &x;  // p can change, *p cannot be changed

So the presence of parenthesis would be simply to limit the extent of 
the type to which "const" applies?

As an aside, I'm still not terribly fond of 'invariant', but that's a 
cosmetic issue which could easily be resolved later.

> o  const and invariant are transitive. There is no way to specify a 
> (pointer to)(const pointer to)(mutable int).

Sounds great to me.

> o  tail invariant for an array or pointer type can be done using the 
> existing syntax:
> 
>  invariant(char)[] s;   // string, i.e. an array of invariant chars
>  const(T)* p;  // pointer to tail const T
> 
> o  tail const of a struct would have to be done by making the struct a 
> template:
> 
>   struct S(T) { T member; }
>   S!(int)   // tail mutable
>   S!(const(int)) // tail const
> 
> o  one can construct a template to generically produce tail const or 
> tail invariant versions of a type.

Could you please explain this further?  Why would templates be needed in 
the above two points?

For the rest, this design sounds a lot more comprehensible than the old 
one, and still seems to address all the situations where I would use const.


Sean