Copying with immutable arrays
Ali Çehreli
acehreli at yahoo.com
Sun Oct 28 23:19:35 PDT 2012
On 10/28/2012 02:37 AM, Tobias Pankrath wrote:
> the struct
> SwA from above does neither correspond to SA nor to SB, it's imo more
> like SC:
>
> struct SC {
> immutable(int)* i;
> }
Just to confirm, the above indeed works:
struct SC {
immutable(int)* i;
}
void main()
{
immutable(SC)[] arr1;
SC[] arr2 = arr1.dup; // compiles
}
> Now a copy would do no harm, everything that was immutable in the source
> and is still accessable from the copy is immutable, too. Any reason
> (despite of implemenational issues) that this is not how it works?
Getting back to the original code, the issue boils down to whether we
can copy imutable(string[]) to string[]:
import std.stdio;
struct SwA {
string[] strings;
}
void main()
{
immutable(SwA)[] arr1;
writeln(typeid(arr1[0].strings));
}
The program prints the following:
immutable(immutable(immutable(char)[])[])
Translating the innermost definition as string:
immutable(immutable(string)[])
Let's remove the struct and look at a variable the same type as the member:
immutable(string[]) imm = [ "a", "b" ];
writeln(typeid(imm));
The typeid is the same:
immutable(immutable(immutable(char)[])[])
So we can concentrate on 'imm' for this exercise. This is the same
compilation error:
immutable(string[]) imm = [ "aaa", "bbb" ];
string[] mut = imm; // <-- compilation ERROR
If that compiled, then both 'imm' and 'mut' would be providing access to
the same set of strings. But the problem is, 'mut' could replace those
strings (note that it could not modify the characters of those strings,
but it could replace the whole string):
mut[0] = "hello";
That would effect 'imm' as well. ('imm' is the equivalent of SwA.strings
from your original code.)
Ali
More information about the Digitalmars-d-learn
mailing list