www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - string concatenation

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
TDPL boasts the code:

void main()
{
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
}

We are having second thoughts about allowing b ~ c. It may be just a bit 
too clever. Also, figuring out the result type is not a slam dunk. The 
pro arguments are that strings are already supported by the compiler in 
iteration, literals, and concatenation of a char[] with a dchar.

What say you?


Andrei
Nov 18 2009
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 TDPL boasts the code:
 
 void main()
 {
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
 }
 
 We are having second thoughts about allowing b ~ c. It may be just a bit
 too clever. Also, figuring out the result type is not a slam dunk. The
 pro arguments are that strings are already supported by the compiler in
 iteration, literals, and concatenation of a char[] with a dchar.
 
 What say you?
 
 
 Andrei


What are the current ideas on result type and why don't they dunk?

(personally, I like the idea of a syntax for converting from one unicode
representation to another)
Nov 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 TDPL boasts the code:

 void main()
 {
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
 }

 We are having second thoughts about allowing b ~ c. It may be just a bit
 too clever. Also, figuring out the result type is not a slam dunk. The
 pro arguments are that strings are already supported by the compiler in
 iteration, literals, and concatenation of a char[] with a dchar.

 What say you?


 Andrei


 
 What are the current ideas on result type and why don't they dunk?


The result type would be the type of the left-hand side. This makes ~ 
consistent of sorts with ~=.


 (personally, I like the idea of a syntax for converting from one unicode
 representation to another)


I don't think that's an option at the moment.


Andrei
Nov 18 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 TDPL boasts the code:

 void main()
 {
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
 }

 We are having second thoughts about allowing b ~ c. It may be just a bit
 too clever. Also, figuring out the result type is not a slam dunk. The
 pro arguments are that strings are already supported by the compiler in
 iteration, literals, and concatenation of a char[] with a dchar.

 What say you?


 Andrei


 What are the current ideas on result type and why don't they dunk?


 
 The result type would be the type of the left-hand side. This makes ~
 consistent of sorts with ~=.
 


That seems intuitive enough. Its what I would have guessed.


 (personally, I like the idea of a syntax for converting from one unicode
 representation to another)


 
 I don't think that's an option at the moment.
 
 
 Andrei


I don't know what I ended up saying, but I meant

a = ""c ~ somewstring;

beats

a = std.utf.toString(somewstring);
//no I'm not going to check if that's the right function

am I still missing something?
Nov 18 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Ellery Newcomer wrote:

 
 I don't know what I ended up saying, but I meant
 
 a = ""c ~ somewstring;
 
 beats
 
 a = std.utf.toString(somewstring);
 //no I'm not going to check if that's the right function
 
 am I still missing something?


Crap, have I just inadvertently strengthened the argument against?
Nov 18 2009
prev sibling next sibling parent reply Justin Johansson <no spam.com> writes:
Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 TDPL boasts the code:

 void main()
 {
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
 }

 We are having second thoughts about allowing b ~ c. It may be just a bit
 too clever. Also, figuring out the result type is not a slam dunk. The
 pro arguments are that strings are already supported by the compiler in
 iteration, literals, and concatenation of a char[] with a dchar.

 What say you?


 Andrei


 What are the current ideas on result type and why don't they dunk?


 The result type would be the type of the left-hand side. This makes ~
 consistent of sorts with ~=.


 
 That seems intuitive enough. Its what I would have guessed.
 

 (personally, I like the idea of a syntax for converting from one unicode
 representation to another)


 I don't think that's an option at the moment.


 Andrei


 
 I don't know what I ended up saying, but I meant
 
 a = ""c ~ somewstring;
 
 beats
 
 a = std.utf.toString(somewstring);
 //no I'm not going to check if that's the right function
 
 am I still missing something?


a = string( somewstring )

is much cleaner.

This an example of a constructor function.

Sadly, D does not support constructor functions (that I know of).

Justin Johansson
Nov 18 2009
next sibling parent Justin Johansson <no spam.com> writes:
Justin Johansson wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 a = std.utf.toString(somewstring);
 //no I'm not going to check if that's the right function

 am I still missing something?


 
 a = string( somewstring )
 
 is much cleaner.
 
 This an example of a constructor function.
 
 Sadly, D does not support constructor functions (that I know of).


I meant for primitive types, of course.
Nov 18 2009
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Justin Johansson wrote:

 
 a = string( somewstring )
 
 is much cleaner.


From a syntactic perspective I disagree.

Otherwise yup.
Nov 18 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Ellery Newcomer" <ellery-newcomer utulsa.edu> wrote in message 
news:he2lm6$1h39$1 digitalmars.com...

 Andrei Alexandrescu wrote:

 Ellery Newcomer wrote:

 Andrei Alexandrescu wrote:

 TDPL boasts the code:

 void main()
 {
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
 }

 We are having second thoughts about allowing b ~ c. It may be just a 
 bit
 too clever. Also, figuring out the result type is not a slam dunk. The
 pro arguments are that strings are already supported by the compiler in
 iteration, literals, and concatenation of a char[] with a dchar.

 What say you?


 Andrei


 What are the current ideas on result type and why don't they dunk?


 The result type would be the type of the left-hand side. This makes ~
 consistent of sorts with ~=.


 That seems intuitive enough. Its what I would have guessed.


 (personally, I like the idea of a syntax for converting from one unicode
 representation to another)


 I don't think that's an option at the moment.


 Andrei


 I don't know what I ended up saying, but I meant

 a = ""c ~ somewstring;

 beats

 a = std.utf.toString(somewstring);
 //no I'm not going to check if that's the right function

 am I still missing something?


Isn't there "to!(char[])(whateverKindOfString)"?
Nov 19 2009
prev sibling parent reply Justin Johansson <no spam.com> writes:
Andrei Alexandrescu wrote:

 TDPL boasts the code:
 
 void main()
 {
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
 }
 
 We are having second thoughts about allowing b ~ c. It may be just a bit 
 too clever. Also, figuring out the result type is not a slam dunk. The 
 pro arguments are that strings are already supported by the compiler in 
 iteration, literals, and concatenation of a char[] with a dchar.
 
 What say you?
 
 
 Andrei


Good; have third thoughts as well; the TDPL code is nothing to boast about.

Basically no thanks.

con argument

1. Explicit conversion between string types is clearer to read in source 
code than auto-magic conversion.
2. Value types should be supported by constructor functions (and these
can allow type conversion); hiding construction behind binary operators
is evil.
3. People will end up writing concatenation with empty string to do 
their type conversion.  This is the result of such evil.
4. Programs sprinkled with mixtures of strings, wstrings and dstrings 
are uncommon so it's trying to be a bit too clever to support the 
infrequent use cases.
5. It's less work for you and Walter to not allow such behind the scenes
conversion.

Justin Johansson
Nov 18 2009
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Johansson wrote:

 Andrei Alexandrescu wrote:

 TDPL boasts the code:

 void main()
 {
   string a = "Hall\u00E5";
   wstring b = ", ";
   dstring c = "V\u00E4rld";
   auto d = b ~ c;           // d has type wstring, same as b
   a ~= d ~ '!';             // concatenate string with character
   writeln(a);
 }

 We are having second thoughts about allowing b ~ c. It may be just a
 bit too clever. Also, figuring out the result type is not a slam dunk.
 The pro arguments are that strings are already supported by the
 compiler in iteration, literals, and concatenation of a char[] with a
 dchar.

 What say you?


 Andrei


 
 Good; have third thoughts as well; the TDPL code is nothing to boast about.
 
 Basically no thanks.
 
 con argument
 
 1. Explicit conversion between string types is clearer to read in source
 code than auto-magic conversion.
 2. Value types should be supported by constructor functions (and these
 can allow type conversion); hiding construction behind binary operators
 is evil.
 3. People will end up writing concatenation with empty string to do
 their type conversion.  This is the result of such evil.
 4. Programs sprinkled with mixtures of strings, wstrings and dstrings
 are uncommon so it's trying to be a bit too clever to support the
 infrequent use cases.
 5. It's less work for you and Walter to not allow such behind the scenes
 conversion.
 


Also you'll be calling some behind the scenes runtime library function
to do it anyway, in order to encode the dchars to multiple wchars.

All seems a bit pointless really.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLBaaYT9LetA9XoXwRAgxQAKCwdo12XokImcAX+A97VzmIywNuIgCdH1JG
BTP5L+COxR704lknJMTkjRI=
=Dljj
-----END PGP SIGNATURE-----
Nov 19 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
div0 wrote:

 Also you'll be calling some behind the scenes runtime library function
 to do it anyway, in order to encode the dchars to multiple wchars.
 
 All seems a bit pointless really.


Yeah, my thought too.
Nov 20 2009