Const sucks

[Bill Baxter]

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.
> 
> Andrei and Bartosz have spent some time together going back to square 
> one with what are we trying to achieve with const, and came up with 
> another proposal.
> 
> What we are trying to achieve:
> 
> a) utility for functional programming
> b) better modularity by self-documenting interfaces better
> c) be able to treat reference types as if they were value types (i.e. 
> strings should behave to the user like value types, even though they are 
> references)

Does c) include being able to pass literal arguments to functions 
expecting const-references?  I.e. sort of the opposite: being able to 
treat value types as const-references, even though they are const values.

> 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

I'm very happy that 'const int' will mean something other than 'just 
plain int'.  The always-off-by-one part of the current design is hard to 
get enthusiastic about.  But this one makes more sense.

Maybe you might consider Janice's suggestion for the structs, though:

const(S)* // Pointer to S nonconst, S is const
const(S)  // S const
const*(S)  // S nonconst, but stuff accessed via S is const
const**(S)  // S and S.member nonconst, but stuff accessed via S.member
is const

--bb