www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - concatenation

reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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[] ?
Jan 24 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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/
Jan 24 2011
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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
Jan 24 2011
prev sibling next sibling parent Simon Buerger <krox gmx.net> writes:
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
Jan 24 2011
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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.
Jan 26 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
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
Jan 24 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Jan 25 2011
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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
Jan 26 2011