Proposal - Revised Syntax for const and final

[Bill Baxter]

Nathan Reed wrote:
> Janice Caron wrote:
>> 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).
> 
> Agree.  And for what it's worth, I agree with you about losing the 
> storage-class version of const.  I also agree with using some different 
> syntax to denote tail-constness, since having const(S) for S a struct 
> mean that S's members are mutable is unintuitive.
> 
> Ultimately, though, I think constness is always going to work 
> differently for value types than reference types.  After all, the whole 
> reason we have both kinds of types is that they are both useful, and 
> have different semantics - hence we shouldn't try *too* hard to pretend 
> they're the same thing. (A pointer to a struct should behave the same as 
> a reference to an object though.)

I think there are some good points in what you're saying too.  I mean I 
could pretty much *understand* your proposal, so that's a good thing 
right there.

I do also particularly like sliding where the tail begins using *'s.  It 
seemed kind of logical to me.  The *'s let you specify how far down the 
tail starts relative to the part of the type inside parens.  Easy to 
remember and reminiscent of the duality of  P* x vs P *x in C:

P*  x  -- "x is a pointer to P"
vs
P  *x  -- "a dereferenced x is a P"

If you take a * off one side, you have to put it on the other to keep 
the same meaning.   Similarly with your const(int*)**.  If you move a * 
inside the parens, you have to balance it by putting one back after the 
const to maintain the same meaning.  Or put another way const*(int**) 
means 'dereference once before applying the const to what's in 
parentheses'  I'm not sure how Walter's syntax handles the same case but 
your way makes it very easy to create a const type that applies one 
level deeper than the original type by saying const*(T).  Analogously, 
maybe const&(T) could be made to mean one level higher (== closer to head).


--bb