Const sucks

[Derek Parnell]

On Mon, 10 Sep 2007 12:15:09 -0700, 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.

Agreed!

> 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)

Ok, nice to see this documented.

> The insights they came up with were:
> 
> 1) final (i.e. 'head const') is not necessary for a, b or c. final is a 
> local thing, and not strictly necessary.
> 
> 2) tail const can be handled in other ways, read on
> 
> So, what we are left with is:
> 
> o  no more final

Not a problem for me as I never used it.
 
> o  const and invariant now mean "fully const" and "fully invariant", 
> where fully means "head and tail combined":

Remind me again what the difference between 'const' and 'invariant' is.

> 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


What do these below mean ...

  const int (* p)
  const int *(p)
  const int (*) p


 
> 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

But most structs contain multiple members, and usually of different types.
 
-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell