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[] ?

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.

-- 
Robert
http://octarineparrot.com/

Robert Clipsham <robert@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

Ellery Newcomer <ellery-newcomer@utulsa.edu> 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[] ?

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

-- 
Simen

On 25.01.2011 00:22, Robert Clipsham wrote:
> 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.
>

This is true in a more general sense, but not for string-concatenation. The ~ operator always creates a copy of the array elements. So even with
y = x ~ "";
y will point to different data than x, so it would be okay to be mutable.

Your statement is however true for arrays of Object/Pointer/any-reference-type instead of simple chars.

Krox

On Mon, 24 Jan 2011 18:39:39 -0500, Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> Ellery Newcomer <ellery-newcomer@utulsa.edu> 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[] ?
>
> http://d.puremagic.com/issues/show_bug.cgi?id=1654

I have since felt that the bug report I filed may be more trouble than it's worth.  It makes perfect sense for strings or other arrays of non references, but it doesn't make sense for more complex types (as can be seen by the later discussions on that report).

From the original issue, s ~ x is concatenating two different types, what should the result type be?  Either choice is going to cause problems.  The only "correct" choice is a polysemous type that can implicitly cast into either type on the assumption that the data is unique.  This is pretty much what I wanted from the bug report, but I was very green back then, didn't know the right way to say it.

If the enhancement can be implemented, I think it would help, but it would be nice to solve this problem in the general sense (not just for arrays).  There was a suggestion earlier that a strong-pure function could return an implicitly castable type, but concatenating a mutable and immutable string would not be such a function.  We would need some other way to mark a function.

-Steve

"Ellery Newcomer" <ellery-newcomer@utulsa.edu> wrote in message news:ihl0vh$1n8v$1@digitalmars.com...
> 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[] ?

This seems to be the same thing, or at least related http://d.puremagic.com/issues/show_bug.cgi?id=1654

On 01/24/2011 05:22 PM, Robert Clipsham 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.
>

If you append something mutable to something immutable, the resulting type can't be mutable, as some of the contents are immutable and may not be changed - if you let the result type be mutable you've frivolously done away with the type system's protection of the immutable elements.

const(char) makes more sense to me from that front.

char is a value type and x is always going to get copied, so mutability isn't really an issue in this case.

number of copy operations might be, though.

y = s ~ x.idup;

is

COPY(s, COPY(x))

as I understand things. Be nice if dmd could flatten the copying.