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 reply "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
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