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
