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