Proposal - Revised Syntax for const and final

[Bill Baxter]

Janice Caron wrote:
> OK, I guess you're right about PODs. Let's try again, but more generally:
> 
> Regardless of the type of T:
> 
> final(T) would be a type that was similar to T except that it would be
> const, its members would be mutable, and all of its members' members
> would be mutable, etc..
> 
> const(T) would be a type that was similar to T except that it would be
> const, its members would be const, and all of its members' members
> would be const, etc..
> 
> const*(T) would be a type that was similar to T except that it would
> be mutable, its members would be const, and all of its members'
> members would be const, etc..
> 
> const**(T)  would be a type that was similar to T except that it would
> be mutable, and its members would be mutable, but its members' members
> would be const, etc..
> 
> Now, if some of those possibilities turn out to be nonsense (e.g
> final(int), then we can always make those possibilities compile-time
> errors.
> 
> But it would be consistent, logical, and a boon to generic programming.
> No?

I think you need to be more specific when you say "members" because S 
and S* both have the same exact "members" syntactically.  But I would 
expect const*(S) and const*(S*) to behave differently.  So maybe you 
should be talking about levels of dereferencing instead?

Also what happens with an alias like
    alias S* T;
const*(S*) better behave the same as const*(T) or there'll be trouble. 
Replacing a type with an alias of the same type should never change 
behavior.

But if T *does* continue to act like S*, then is that so different from 
what you have now with class references?  They're called C but they act 
like C_* for some underlying (but inaccessible) base struct C_.

--bb