any news on const/invariant?

[Bill Baxter]

Walter Bright wrote:
> Derek Parnell wrote:
>> The simple fact is that
>>    const type funcname();
>>
>> looks ambiguous. It LOOKS like it could mean either that funcname() 
>> returns
>> a const type OR that funcname() is const but returns a non-const type.
>>
>> Once you know the rules you can workout what is intended, but it is 
>> not as
>> intuitive as you might like it to be.
>>
>> Will it really be so hard to provide syntax that is not so ambiguous?
>>
>> Also, what is the syntax for a const function that returns a const type?
> 
> The rule for constructing a const type is to enclose that type in 
> parentheses, so:
>     const const(type) funcname();
> or:
>     const(type) funcname()const;
> or:
>      const
>      {
>     const(type) funcname();
>      }
> 
>> Walter, your efforts to achieve simplicity are being thwarted by the
>> results being simplistic.
> 
> I think it is thwarted by people believing it is far more complicated 
> than it actually is. For example, in the above case, you have to use 
> const twice, because there are two different things in the same 
> declaration you want to be const. Forget about const as a storage class 
> for the moment, and just think of const as a type constructor. To make a 
> type const,
>     const(T)
> and it will all follow from there.


That's a good way to remember it.   If we get used to seeing and writing 
cosnt(T) everywhere C++ would have said "const T", then it should become 
natural to see    const int foo() as a "const(this)" rather than 
returing const int.

--bb