Inability to dup/~ for const arrays of class objects

[Peter Williams]

On 29/05/13 09:58, Steven Schveighoffer wrote:
> In fact, const(T)[] applies ONLY to the data in the array, the array
> itself is not const.  A fully const array is:
>
> const(T[])
>
> Which cannot be appended to or modified.

Thanks, I'll change my code.

>
> However, a const(T[]) implicitly casts to a const(T)[].
>
>> If this behaviour is a deliberate design decision
>
> It is
>
>> I'll accept that and (probably) modify my code to use (cast(T[])).dup
>> in all cases.  (At the moment, I'm using a single mixin template to
>> handle this issue and the inability to use ==, !=, < and friends with
>> constant class objects. When that problem goes away I'll do the above
>> modifications.)
>
> This is not a good idea.  You are circumventing const.

Unfortunately, I have to circumvent const just to use ==, <=, etc in the 
current incarnation of D.  So this won't make things worse.

>  What you want is a deep copy.

No, I don't.

I'm implementing sets and the concept is sets of objects not sets of the 
values in the objects.  I want to be able to initialize sets using 
arrays and I'm promising that I won't change the array or its contents. 
  I'm also trying to promise that I won't (inside the set 
implementation) make any changes to individual objects.  But I'm not 
promising that they won't be changed by other code that has access to 
them.  The invariant (I wrote) for the sets implies that any changes 
made by that code can't change the sort order of the objects.

>
> In all likelihood, the problem could be that you are using classes and
> really should be using structs.

No, I really don't want copies although I can see that might have it's 
uses in another application.  It's the mathematical concept of sets that 
I'm trying for not just containers.  I.e. it's a way of selecting groups 
of objects, combining groups without duplicates, etc.

Peter