const again

[Walter Bright]

Janice Caron wrote:
> On 12/6/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>> There are a couple problems with it, the worst of which is its impact on
>> generic code:
>>         const(T)[]
>> Would you put the & there or not?
> 
> Good point. You'd need it for a class, but not for a struct. I hadn't
> thought of that.
> 
> That said, would that be much of a problem?

I think it would be, especially from the point of view of generic 
programming.

> Arrays of structs are very
> different beasts from arrays of class references. The copy semantics
> alone are different enough that one might imagine that generic code
> would need one or two if(is(T==struct))s in there anyway.

The less of such special casing the better <g>.

>> What would & mean if one wrote:
>>         struct S { C c; }
>>         const(S)&[] a;
>> ?
> 
> I had in mind that that would be a syntax error.

A special syntax for class types means that one has to know that type T 
is a class.

>> One principle we try to adhere to is that it should make sense to be
>> able to wrap any type with a struct, and have it be possible for that
>> struct to behave as if it were that member type.
> 
> If we went with the & syntax, then that principle would dictate the
> requirement of an additional operator overload, which for want of a
> better name I shall temporarily call opAmpersand.

You see how pulling on that string brings us more and more special cases 
and problems :-( I won't say this is impossible, but it's always 
something we can think about later after we have more experience with const.

>> And finally, this suggests that & means "tail-const".
> 
> I prefer to think that it means "reference to", in the same way that *
> means "pointer to". However, this is D, not C++, so the symbol would
> only be allowed for types which were /already references/, in which
> case it could be used to indicate tail constness by placing the symbol
> outside the brackets. Note that const(C&) would mean exactly the same
> thing as const(C) - so it's not the ampersand that means tail-const,
> it's its placement.
> 
> 
>> 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).
> 
> Forgive me - perhaps I haven't thought this through deeply enough. I
> don't follow why that's a problem.

If one has a tail-const struct, do you call the mutable member function 
or the const member function?