any news on const/invariant?

[Walter Bright]

Janice Caron wrote:
> On Nov 28, 2007 10:10 AM, Walter Bright <newshound1 at digitalmars.com> wrote:
>> I think it would be pretty hard to give up:
>>
>>       const x = 3;
> 
> Why? It would just turn into something else, like
> 
>     const(int) x = 3;
>     static x = 3;
>     macro x = 3;

Because those alternatives all look terrible. And frankly, how could 
anyone be confused about what:
	const x = 3;
means? I can't understand throwing that out to improve clarity?


>> Also, C++ has const as both a storage class and a type constructor, and
>> yes, they have subtly different meanings. This doesn't seem to cause any
>> major problems.
> 
> That's because C++ behaves as expected. If I declare
> 
>     const int * f();
> 
> then I get a function which returns a pointer to const int, /not/ a
> const member function which returns a pointer to mutable int.

What is expected, or what you are *used* to? Let me put it another way, 
can you explain the difference between C++ const storage class and C++ 
const type constructors? There's a big semantic difference.


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