const again

[Steven Schveighoffer]

"Walter Bright" wrote
> 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.

const(T)*[] x;

x[0].member is a struct member if T is a struct, what is it if T is a class? 
I was under the (possibly wrong) impression that this is illegal?

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

I totally agree.  I don't think struct variables should become references. 
I was saying there should be a way to mean "reference to either struct or 
class" to make generic code with tail-constness easier to write

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

Sure, but your original point was 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".  I believed you were 
implying that this was a reason NOT to have a & operator.  My question to 
you is, how does having a reference operator make this more difficult than 
not having one?  A reference is a pointer.  We already have those, I have no 
reason to believe that they are any less wrappable than a pointer?

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

OK, I am confused, isn't const(S)* tail const?  And if so, how does this new 
scheme rid us of tail const?  Couldn't I use this to call a const member 
function on a struct?

The way I am interpreting your new const is that I can have tail-const for 
struct references (pointers) but not tail-const for class references.  It 
seems to me it would be more important to have classes be const, why is your 
new way better?

In other words, I can create a tail-const struct array via:

const(S)*[] tailconst;
tailconst[0] = new S; // ok to assign to tailconst[0]
tailconst[0].nonconstfunc; // error, cannot call const function

How do I do the same for a class?  I don't want to have to use a * operator 
because I don't have to do that for structs.  I want to make generic code.

-Steve