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.
Then you are trying to make a *momentary* guarantee.
In essence, you want to transform the array into a set, but still
guarantee that the underlying data hasn't changed.
This is very difficult to express with the type system. The closest you
can get is inout, which *might* be able to do it.
For example:
inout(T)[] copyIt(T)(inout(T)[] arr)
{
// this is quirky, but it's the easiest way to do it without an
equivalent .dup for inout
inout(T)[] result;
result ~= arr;
return result;
}
Now, if you pass in mutable, you get mutable. If you pass in const, you
get const. If you pass in immutable, you get immutable.
I say *might* because I don't know what your code is doing, or how your
set type actually looks. It may be logical, but impossible to currently
express. inout still has some room for improvement (and so does the whole
const system in general).
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.
Another option is to simply define your types as "immutable" types. That
is, specify the data inside is immutable, but the class itself is not.
e.g.:
class C
{
immutable int c;
this(int x) { c = x;}
}
You are hitting a very common pain-point for const/immutable, for which
there is really not a good answer currently.
-Steve
