Proposal - Revised Syntax for const and final

[Janice Caron]

> I think this has to be modified to: final(T) would be a type similiar to
> T except that its value would be const, but anything accessed indirectly
> through its value would be mutable.

Yes. I kind of hoped that was implicit in what I said, but that's what
I meant anyway.


> Hence,
>
> struct S {
>      int a;
>      int* p;
> }
>
> final(S) s;
> s = S(47, 0);   // error, s is const
> s.a = 47;       // error, s is const
> *s.p = 47;      // ok, value pointed to by p is mutable

You're right.

Although now we're back to square one, because now structs and classes
behave differently once again. <Sigh>.

Ah well - maybe this plan won't work. Or maybe it will and just needs
a bit more refinement. Who knows?

All I know for sure is that the existing D2.0 scheme is too confusing.
The fact that
const(int**) s;
const(int*)* s;
both mean the same thing is highly counterintuitive. If we're stuck
with the current scheme, I would prefer that the first version be
declared a compile-time error (since s can in fact be assigned).