concatenation

[Simen kjaeraas]

Robert Clipsham <robert at octarineparrot.com> wrote:

> On 24/01/11 23:09, Ellery Newcomer wrote:
>> in the following:
>>
>> void main(){
>> char[] x;
>> string s;
>> string y;
>>
>> y = s ~ x;
>> }
>>
>> tok.d(5): Error: cannot implicitly convert expression
>> (cast(const(char)[])s ~ x) of type char[] to string
>>
>> why should typeof(s ~ x) == char[] ?
>
> x is a mutable array of mutable chars
> s is a mutable array of immutable chars
>
> If you append something mutable to something immutable, the resulting  
> type must be mutable, as some of the contents is mutable and could be  
> changed - if that can happen the result can't be immutable. To get  
> around this there's .idup I believe.

That is actually a very good argument in favor of const(char)[] as the
result type.

See, for a given T[] and immutable(T)[], where T is or holds pointers,
the immutability invariant would be broken if the result type were T[],
and the conversely, elements might change from under you if the result
were immutable(T)[].

For T where T has and holds no pointers/references, unique(T)[] would
be the best, if the language supported it.

This would give us this constancy chart:
      unique
     /     \
mutable immutable
     \     /
      const

Where the elements on each layer can be implicitly converted to those
below it. Functions could then return unique results when the return
type can be proven to be unique.

There are complications to such a scheme though, but I'm not gonna
enumerate those right now.

-- 
Simen