[Issue 1654] Array concatenation should result in mutable or invariant depending on usage

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1654





------- Comment #13 from brunodomedeiros+bugz at gmail.com  2008-05-01 12:34 -------
(In reply to comment #2)
> However, this could be alleviated if we had the following rule:
> if X is a data type, and v1 is of the type invariant(X) and v2 is of the type
> X, it is allowed to copy v1 to v2 provided that the X data type is not a
> pointer or a reference or contains any pointers or references.
> I think this rule is sound and really should be an enhancement on its own, but
> it provides a way that my solution could work.  With this rule, my example
> passes the rule since copying an invariant(char) to a char is allowed, but your
> example fails because copying an invariant(int[]) to a int[] fails.
> What do you think?

"copying an invariant(int[]) to a int[]" fails indeed, but copying
invariant(int[]) to an invariant(int)[] would work as well.
So basicly what we are looking into here is tailconst. The concatenation of a
const(T)[] with another const(T)[] conceptually returns a type that is:

  tailconst(T)[]

and similarly for invariant/tailinvariant. This is because the "head-value" of
T is copied, so it can be mutable. So these semantics are safe:

int[] ~ int[]                           --> returns int[]
const(int)[] ~ const(int)[]             --> returns int[]
int[][] ~ int[][]                       --> returns int[][]
const(int[])[] ~ const(int[])[]         --> returns const(int)[][]
const(int)[][] ~ const(int)[][]         --> returns const(int)[][]

How about this though? :

const(Foo)[] ~ const(Foo)[]             --> returns ???

Unfortunately there is no way in D to express tailconst for classes (and
structs), so the last example would have to use normal const(T) instead of
tailconst(T). I'm not sure what the implications of this special, and
inconsistent case are tough, it could break generic code or something. Which
does not mean these semantics would not be worthwhile.


--