Inability to dup/~ for const arrays of class objects

Diggory diggsey at googlemail.com
Tue May 28 18:59:23 PDT 2013


On Wednesday, 29 May 2013 at 01:33:57 UTC, Steven Schveighoffer 
wrote:
> On Tue, 28 May 2013 21:19:49 -0400, Ali Çehreli 
> <acehreli at yahoo.com> wrote:
>
>>     // C is a class
>>     const(C) c = new const(C);
>>
>>     // c promises that it won't mutate the object.
>>     // Why can't it promise to not mutate another object?
>>
>>     c = new const(C);  // <-- compilation error
>>
>> I don't see the rationale for disallowing the last line. I 
>> think it should work without any syntax change. Merely the 
>> class handle is being changed.
>
> The issue is that you cannot separate out the reference from 
> the referred-to data, and apply const only to the tail.
>
> It's a syntax issue, not a semantic issue.  It should be 
> allowed, but we lack the syntax to specify it.  You can only 
> apply const to both the reference and the data.
>
> -Steve

At the moment type qualifiers are also implicitly storage 
classes, I wonder if it would cause any problems to separate the 
two uses out...

For a class:
const(C) myvar;   // Normal variable holding a const(C)
const C myvar;    // Const variable holding a const(C) (due to 
transitivity)

For a struct:
const(S) myvar;   // Const-ness of struct leaks out to variable 
because it is a value type
const S myvar;    // Const variable holding a const(S) (due to 
transitivity)


More information about the Digitalmars-d mailing list