const again

[Walter Bright]

Steven Schveighoffer wrote:
> What happens if you have this?
> const(T)*[]

Array of pointers to constant T.

> If T is a struct, then it's fine, but if it's a class, then what?  To me the 
> situation is just as bad.

It is perfectly consistent. I don't see why it is bad.

> This whole problem stems from the fact that a struct declaration is a value 
> type and a class declaration is a reference type, but they look the same. 
> You are never going to have a consistent syntax for generic const code 
> because you don't have a consistent syntax for normal declarations.

Having distinctly different value and reference aggregates is, in my 
opinion, a good thing.

> const (X)* m;
> 
> Please tell me how you will replace m with a 'smart' pointer type that is 
> mutable, but the pointer contents are not.

That's the way it works now. You can modify m, but not X.


>> And finally, this suggests that & means "tail-const". Tail-const has that 
>> severe problem that there is no such thing as a tail-const member function 
>> (i.e. a member function that can modify the fields of the object, but not 
>> anything those fields refer to).
> 
> Huh?  I thought tail-const was that you could change the reference but not 
> the members?

Yes, that's exactly what tail-const is.