const again

[Steven Schveighoffer]

"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> "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?
>
> I don't understand. Exactly what is illegal?

I guess it isn't :)  I thought:

class C { void f() {} }

C c = new C;
C *cp = &c;
cp.f(); // I thought this was illegal, but it works!

So you CAN still have tail-const.  The only issue is that you need to have a 
reference to take the address of...

It would be nice if I could just do:
C * cp = new C;

Then I could have generic code like:

const(T)*[] x

x = new const(T)*[5]

for(int i = 0; i < 5; i++)
  x[i] = new T; // this will work for structs, not for classes

then we have functionally tail-const back...

I think this isn't going to be possible, because then you have no way of 
specifying I want a reference of a reference.  Like a ref parameter.

This is why I proposed that the & operator is used to mean 'pointer to'. 
The benefit is:

T x; // for classes, this means pointer, for structs, it means value
T *x; // for classes, this means pointer to pointer, for structs it means 
pointer.
T &x; // for classes, it means pointer, for structs, it means pointer

>
>
>> 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.
>
> There's the problem we're having. While a class reference is implemented 
> as a pointer 'under the hood', to the type system, it is not a pointer.
>
>
>> OK, I am confused, isn't const(S)* tail const?
>
> No. For const(int*), tail const of that construct would mean that the 
> pointer is mutable while what it points to is not.

I believe I understand your confusion.  To me tail-const == reference is 
mutable, pointed to data is not.  I think of this as the semantic meaning of 
tail-const regardless of what the syntax says

To you, tail-const is the specific syntax of const(C) for a reference type 
meaning C is tail-const.  I agree that this is confusing, and bad for 
generic code.  But const(C)* under the new regime is still functionally 
tail-const, is it not?

>
>
>> And if so, how does this new scheme rid us of tail const?
>
> It would say that const(int*) would mean an immutable pointer to an 
> immutable int.
>
>> Couldn't I use this to call a const member function on a struct?
>
> I'm very confused as to what you're referring to.

I was confused also :)  I think the new regime allows tail const, but makes 
it difficult to make tail-const references to classes.

>> 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.
>
> No. The correct interpretation is that all parts of the type within the 
> ( ) are immutable.

I understand this and agree with it.

>> 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?
>
> You cannot separate the class reference from the class fields.

That is why I proposed a new syntax.  If you want to do const in a way that 
is correct and backwards compatible, I think you cannot avoid this.  To 
allow for more power for structs to easily have tail const, but not classes 
seems very wrong to me.

-Steve