any news on const/invariant?

[Bill Baxter]

Walter Bright wrote:
> Janice Caron wrote:
>> On Nov 28, 2007 10:10 AM, Walter Bright <newshound1 at digitalmars.com> 
>> wrote:

>> I other
>> words, in C++, the const adheres to the return type, not the
>> function's "this" pointer. The D behaviour is drastically different
>> and vastly unintuitive.
> 
> D's const storage class applies to the declaration. That makes intuitive 
> sense, although it is different from C++.
> 
> 
>> I don't know whether this is syntactically considered to be a storage
>> class or a type constructor in C++, but really, it's irrelevant to me.
>> What matters is the principle of least surprise. It should do what we
>> expect it to do, and not something else.
> 
> Every other storage class applies to the declaration, why should const 
> be completely different?

We're talking here about methods, right?  And you're saying if we can do 
this:
     static int[] func() { }

then why shouldn't we be able to do this:
     const int[] func() { } ??

(Just trying to make sure I understand your point.)

Acutally, when comparing side by side with "static", that starts to 
sound reasonable.   Both are mucking with func's implicit 'this' 
paramter (static eliminates it, const makes it const).

The big difference is just that 'static int[]' as a return value makes 
no sense, so there's only one way to read it, but "returns a const 
int[]" is a logical way to mis-read the const version, especially for 
C++ converts.

One workaround for people who find that confusing would be to reiterate 
the protection:

     const public int[] func() {}

Which is not much more verbose than

     const(this) int[] func() { }


So I guess I can see people getting used to this.  So the question again 
becomes why allow the at-the-end syntax too?  Isn't one syntax enough? 
Is it just because you want to avoid

     const const int[] func() {}   ?

--bb