www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Kill implicit joining of adjacent strings

reply bearophile <bearophileHUGS lycos.com> writes:
Do you seen anything wrong in this code? It compiles with no errors:

enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
static assert(data[4] == "yellow");
void main() {}


Yet that code asserts. it's an excellent example of why a sloppy
compiler/language sooner or later comes back to bite your ass.
I've recently had another bug caused by automatic joining of adjacent strings.
I think this is the 3rd I have found in my D code. This is enough.

In C the joining of adjacent strings is sometimes useful, but explicit is
better than implicit, and D has a short and good operator to perform joining of
strings, the ~, and D strings are allowed to span multi-lines.

C code ported to D that doesn't put a ~ just raises a compile time error that's
easy to understand and fix. So this doesn't change the meaning of C code, just
asks the programmer to improve the code, and the change requires is fully
mechanical.

The compiler need to be able to perform the joining at compile time, so zero
run-time overhead is present. The result is the same as before, it's just a
syntax change.

My bug report has more info and a partial patch:
http://d.puremagic.com/issues/show_bug.cgi?id=3827


polished, and indeed it refuses automatic joining of adjacent strings:

public class Test {
    public static void Main() {
        string s = "hello " "world";
    }
}



prog.cs(3,35): error CS1525: Unexpected symbol `world'
Compilation failed: 1 error(s), 0 warnings

This is one of the about twenty little/tiny changes I am waiting for D.

So please kill automatic joining of adjacent strings in D with fire.

Thank you,
bearophile
Nov 10 2010
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Nagging is one way to accomplish change, but it's sure annoying.  If you feel
the feature is import, you know where to get the source.  Give it a shot.
Contribution of code is oh so much more valuable than a constant stream of "you
should change..."

Repeatedly claiming that Walter ignores 'X' is another way to get a reaction,
but it's also very annoying.  You're far from the only person to pull this card
out.  Do you _honestly_ believe he's that narrow minded or are you just trying
to get enough of a rise out of such claims that he'll drop what he's doing and
focus on your nag-of-the-day?

Sigh.. it get's old, fast.

Back to lurk mode,
Brad

On 11/10/2010 6:34 PM, bearophile wrote:

 Do you seen anything wrong in this code? It compiles with no errors:
 
 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}
 
 
 Yet that code asserts. it's an excellent example of why a sloppy
compiler/language sooner or later comes back to bite your ass.
 I've recently had another bug caused by automatic joining of adjacent strings.
I think this is the 3rd I have found in my D code. This is enough.
 
 In C the joining of adjacent strings is sometimes useful, but explicit is
better than implicit, and D has a short and good operator to perform joining of
strings, the ~, and D strings are allowed to span multi-lines.
 
 C code ported to D that doesn't put a ~ just raises a compile time error
that's easy to understand and fix. So this doesn't change the meaning of C
code, just asks the programmer to improve the code, and the change requires is
fully mechanical.
 
 The compiler need to be able to perform the joining at compile time, so zero
run-time overhead is present. The result is the same as before, it's just a
syntax change.
 
 My bug report has more info and a partial patch:
 http://d.puremagic.com/issues/show_bug.cgi?id=3827
 

polished, and indeed it refuses automatic joining of adjacent strings:
 
 public class Test {
     public static void Main() {
         string s = "hello " "world";
     }
 }
 

 
 prog.cs(3,35): error CS1525: Unexpected symbol `world'
 Compilation failed: 1 error(s), 0 warnings
 
 This is one of the about twenty little/tiny changes I am waiting for D.
 
 So please kill automatic joining of adjacent strings in D with fire.
 
 Thank you,
 bearophile
Nov 10 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Brad Roberts:


 Nagging is one way to accomplish change, but it's sure annoying.


Right. I was a little too much nervous, sometimes I need to control myself a
little more :-)



 If you feel the feature is import, you know where to get the source.  Give it
a shot.


There is already a partial patch. And modifying just my own version of D is
less than useless.



 Contribution of code is oh so much more valuable than a constant stream of "you
 should change..."


Right.



 Repeatedly claiming that Walter ignores 'X' is another way to get a reaction,
 but it's also very annoying.  You're far from the only person to pull this card
 out.  Do you _honestly_ believe he's that narrow minded or are you just trying
 to get enough of a rise out of such claims that he'll drop what he's doing and
 focus on your nag-of-the-day?


I don't fully understand you. He sometimes ignores 'X', but he's busy, so I
don't expect him to know everything. This is why I have written this and other
posts, to not let this X be ignored.

I am not asking to remove implicit joining of adjacent strings today, but I'd
like this to be considered for future change.



 Sigh.. it get's old, fast.


I don't understamd this speech figure, sorry.

Bye,
bearophile
Nov 10 2010
prev sibling next sibling parent reply "Yao G." <yao.gomez spam.gmail.com> writes:
On Wed, 10 Nov 2010 20:34:07 -0600, bearophile <bearophileHUGS lycos.com>  
wrote:


 Do you seen anything wrong in this code? It compiles with no errors:

 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}


 Yet that code asserts. it's an excellent example of why a sloppy  
 compiler/language sooner or later comes back to bite your ass.


Stop blaming the compiler for your own carelessness.


 In C the joining of adjacent strings is sometimes useful, but explicit  
 is better than implicit, and D has a short and good operator to perform  
 joining of strings, the ~, and D strings are allowed to span multi-lines.


I find it useful, and I like it. I like to break long strings into smaller  
ones
and put each one in one line. I know that you can do that using one single  
string, but
some syntax hightlighters don't like it that way.



 polished, and indeed it refuses automatic joining of adjacent strings:
 [...]
 This is one of the about twenty little/tiny changes I am waiting for D.





 So please kill automatic joining of adjacent strings in D with fire.


No.


 Thank you,
 bearophile



-- 
Yao G.
Nov 10 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Yao G.:


 Stop blaming the compiler for your own carelessness.


If a simple common human error is avoidable at compile-time then it's the duty
of the compiler to avoid it. Blaming the programmer is just silly (and it's
against one of the main "philosophical" differences between C and D). I suggest
you to read some books by Donald Norman about the design of everyday things,
and their error-prone interfaces, that explain very well why you are very wrong:
http://en.wikipedia.org/wiki/Donald_Norman



 I find it useful, and I like it. I like to break long strings into smaller ones
 and put each one in one line. I know that you can do that using one single  
 string, but
 some syntax hightlighters don't like it that way.


This string of yours:

string someText = "I find it useful, and I like it. I like to break long
strings into smaller ones"
    "and put each one in one line. I know that you can do that using one single
string, but"
    "some syntax hightlighters don't like it that way.";

Now becomes:

string someText = "I find it useful, and I like it. I like to break long
strings into smaller ones" ~
    "and put each one in one line. I know that you can do that using one single
string, but" ~
    "some syntax hightlighters don't like it that way.";

Bye,
bearophile
Nov 10 2010
parent reply so <so so.do> writes:
 string someText = "I find it useful, and I like it. I like to break long  
 strings into smaller ones"
     "and put each one in one line. I know that you can do that using one  
 single string, but"
     "some syntax hightlighters don't like it that way.";

 Now becomes:

 string someText = "I find it useful, and I like it. I like to break long  
 strings into smaller ones" ~
     "and put each one in one line. I know that you can do that using one  
 single string, but" ~
     "some syntax hightlighters don't like it that way.";

 Bye,
 bearophile


For 3 lines yes but how about a long file? Not everyone using vim!
What about this one?

"red" "blue" => error

"red"
"blue" => pass

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 10 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
so:


 For 3 lines yes but how about a long file? Not everyone using vim!


There is very little D2 code around... and I don't think very large amounts of
concatenated strings in the source code are a good programming practice.



 What about this one?
 
 "red" "blue" => error
 
 "red"
 "blue" => pass


That's a special case, special cases are bad for the programmer's diet :-)

Bye,
bearophile
Nov 10 2010
parent reply spir <denis.spir gmail.com> writes:
On Wed, 10 Nov 2010 23:10:35 -0500
bearophile <bearophileHUGS lycos.com> wrote:


 For 3 lines yes but how about a long file? Not everyone using vim! =20


=20
 There is very little D2 code around... and I don't think very large amoun=


ts of concatenated strings in the source code are a good programming practi=
ce.

Can't insertion of '~' be easily automated, for extreme cases?=20

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 11 2010
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 11.11.2010 11:16, schrieb spir:

 On Wed, 10 Nov 2010 23:10:35 -0500
 bearophile<bearophileHUGS lycos.com>  wrote:


  >  For 3 lines yes but how about a long file? Not everyone using vim!

  There is very little D2 code around... and I don't think very large amounts
of concatenated strings in the source code are a good programming practice.


 Can't insertion of '~' be easily automated, for extreme cases?

 Denis
 -- -- -- -- -- -- --
 vit esse estrany �

 spir.wikidot.com


or please, all around stop asking for stuff like that, what in hell is 
the benefit, are all developers around my just typing in orgies for 
strings into its sources and these n "~" are too much... i don't get it
Nov 11 2010
parent reply spir <denis.spir gmail.com> writes:
On Thu, 11 Nov 2010 11:18:19 +0100
dennis luehring <dl.soluz gmx.net> wrote:


 Am 11.11.2010 11:16, schrieb spir:

 On Wed, 10 Nov 2010 23:10:35 -0500
 bearophile<bearophileHUGS lycos.com>  wrote:


  >  For 3 lines yes but how about a long file? Not everyone using vim!

  There is very little D2 code around... and I don't think very large a=






mounts of concatenated strings in the source code are a good programming pr=
actice.

 Can't insertion of '~' be easily automated, for extreme cases?

 Denis
 -- -- -- -- -- -- --
 vit esse estrany =C3=A2=EF=BF=BD=C2=A3

 spir.wikidot.com


=20
 or please, all around stop asking for stuff like that, what in hell is=20
 the benefit, are all developers around my just typing in orgies for=20
 strings into its sources and these n "~" are too much... i don't get it


Man, you misunderstood. I meant a transition tool to help with imcompatibil=
ity.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 11 2010
parent dennis luehring <dl.soluz gmx.net> writes:
Am 11.11.2010 14:28, schrieb spir:

 On Thu, 11 Nov 2010 11:18:19 +0100
 dennis luehring<dl.soluz gmx.net>  wrote:


  Am 11.11.2010 11:16, schrieb spir:
  >  On Wed, 10 Nov 2010 23:10:35 -0500
  >  bearophile<bearophileHUGS lycos.com>   wrote:
  >
  >>   >   For 3 lines yes but how about a long file? Not everyone using vim!
  >>
  >>   There is very little D2 code around... and I don't think very large
amounts of concatenated strings in the source code are a good programming
practice.
  >
  >  Can't insertion of '~' be easily automated, for extreme cases?
  >
  >  Denis
  >  -- -- -- -- -- -- --
  >  vit esse estrany âￜ£
  >
  >  spir.wikidot.com
  >

  or please, all around stop asking for stuff like that, what in hell is
  the benefit, are all developers around my just typing in orgies for
  strings into its sources and these n "~" are too much... i don't get it


 Man, you misunderstood. I meant a transition tool to help with imcompatibility.


got it, but do you really thing it will be used that much - i can't 
remember more that 10 occurences of this in the last 14 years (and mio. 
lines of readed code)

its in whole a complete useless discussion, remove it as fast as 
possible - i personaly think, no one will ever cry because of this


 Denis
 -- -- -- -- -- -- --
 vit esse estrany �

 spir.wikidot.com
Nov 11 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 10 November 2010 18:56:02 Brad Roberts wrote:

 Nagging is one way to accomplish change, but it's sure annoying.  If you
 feel the feature is import, you know where to get the source.  Give it a
 shot. Contribution of code is oh so much more valuable than a constant
 stream of "you should change..."
 
 Repeatedly claiming that Walter ignores 'X' is another way to get a
 reaction, but it's also very annoying.  You're far from the only person to
 pull this card out.  Do you _honestly_ believe he's that narrow minded or
 are you just trying to get enough of a rise out of such claims that he'll
 drop what he's doing and focus on your nag-of-the-day?
 
 Sigh.. it get's old, fast.


If nothing else, the sheer number of requests guarantees that they won't all be 
done even if they were all great and really should be done. Bearophile does
have 
a lot of good things to say, but he says so much so often that sometimes it 
becomes hard not to just tune him out.

As for this particular request, I tend to agree. I don't see in point in 
adjacent strings concatenating. I never write my code that way, and it does
seem 
error-prone. I'm not sure that I'm all that against it being in the language, 
but if it were my choice, I wouldn't have had it.

- Jonathan M Davis
Nov 10 2010
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 11 Nov 2010 04:34:07 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:


 So please kill automatic joining of adjacent strings in D with fire.


Yes please. I didn't even know this feature existed in D, but I was  
recently bitten by a bug in a C++ program - also due to a missing comma in  
an array of string literals.

Yao G.: use ~.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Nov 10 2010
prev sibling next sibling parent so <so so.do> writes:
 "blue" "red"


I guess it exists because of a few use cases other than this one.
For this particular example, you are right i couldn't see it and i checked  
two times!

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 10 2010
prev sibling next sibling parent Pillsy <pillsbury gmail.com> writes:
so wrote:


 "blue" "red"





 I guess it exists because of a few use cases other than this one.


It's sometimes nice to be able to break up really long string literals, but it
looks like it's mostly a C holdover. In C it helps with some preprocessor
macros, but D doesn't have preprocessor macros, so the main reason for having
it isn't there.

Either way, it's not exactly a make or break feature.

Cheers,
Pillsy
Nov 10 2010
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 11/10/2010 19:34, bearophile wrote:

 Do you seen anything wrong in this code? It compiles with no errors:
 
 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}
 
 
 Yet that code asserts.


Wait, what?  That's a static assert.  How can it both assert and compile
with no errors?

As it turns out, the joining of adjacent strings is a critical feature.
 Consider the following:
  f("a" "b");
  f("a" ~ "b");
These are /not/ equivalent.  In the former cases, 'f' receives a string
literal as argument, which means that the string is guaranteed to be
zero terminated.  In the latter case, 'f' receives an expression (which
can be evaluated at compile time) as argument, so the string may not be
zero terminated.  This is a critical difference if 'f' is a (wrapper
around a) C function.


-- 
Rainer Deyke - rainerd eldwood.com
Nov 10 2010
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 11 Nov 2010 06:51:38 +0200, Rainer Deyke <rainerd eldwood.com>  
wrote:


 On 11/10/2010 19:34, bearophile wrote:

 Do you seen anything wrong in this code? It compiles with no errors:

 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}


 Yet that code asserts.


 Wait, what?  That's a static assert.  How can it both assert and compile
 with no errors?

 As it turns out, the joining of adjacent strings is a critical feature.
  Consider the following:
   f("a" "b");
   f("a" ~ "b");
 These are /not/ equivalent.  In the former cases, 'f' receives a string
 literal as argument, which means that the string is guaranteed to be
 zero terminated.  In the latter case, 'f' receives an expression (which
 can be evaluated at compile time) as argument, so the string may not be
 zero terminated.  This is a critical difference if 'f' is a (wrapper
 around a) C function.


Wait, so you imply that if I pass 2+2 as a parameter to a function with  
lazy parameters, the compiler should not do partial expression calculation  
and should actually add up 2+2 at runtime? Because, AFAICS, concatenating  
two string literals should be no different from adding two numbers.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Nov 10 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Rainer Deyke wrote:

 On 11/10/2010 19:34, bearophile wrote:

 Do you seen anything wrong in this code? It compiles with no errors:

 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}


 Yet that code asserts.


 
 Wait, what?  That's a static assert.  How can it both assert and compile
 with no errors?
 
 As it turns out, the joining of adjacent strings is a critical feature.
  Consider the following:
   f("a" "b");
   f("a" ~ "b");
 These are /not/ equivalent.  In the former cases, 'f' receives a string
 literal as argument, which means that the string is guaranteed to be
 zero terminated.  In the latter case, 'f' receives an expression (which
 can be evaluated at compile time) as argument, so the string may not be
 zero terminated.
  This is a critical difference if 'f' is a (wrapper
 around a) C function.


But in D, unlike C and C++, constant folding is guaranteed to happen for 
built-in types (and it happens in the semantic pass, not in the 
backend). So in reality, there's no difference.
The docs just need to state that (string literal ~ string literal) is 
still null terminated -- that's the only thing that is missing.
Nov 11 2010
parent reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
Don wrote:


 that's the only thing that is missing


Disagreed.

One of the main points of all languages is to emphasize ones aim, 
espacially if there is a chance of misinterpretation because of the 
language.

Example: there is only a tiny change in the characters from `31415' to `
3.1415'. Without function overloading this can be detected in D, because 
the type of actual parameters changes and Walter dismissed automatic type 
changes from `real' to `int'.

The situation the OP described sams quite similar to me.
-manfred
Nov 11 2010
parent reply Don <nospam nospam.com> writes:
Manfred_Nowak wrote:

 Don wrote:
 

 that's the only thing that is missing


 
 Disagreed.
 
 One of the main points of all languages is to emphasize ones aim, 
 espacially if there is a chance of misinterpretation because of the 
 language.
 
 Example: there is only a tiny change in the characters from `31415' to `
 3.1415'. Without function overloading this can be detected in D, because 
 the type of actual parameters changes and Walter dismissed automatic type 
 changes from `real' to `int'.
 
 The situation the OP described sams quite similar to me.
 -manfred  


I was replying to Rainer, not to the OP.
At present in the compiler there is no difference between "a" "b" and
"a" ~ "b". So implicit joining could be disallowed with loss of 
functionality. But that fact isn't clear from the docs.
Nov 11 2010
next sibling parent "Manfred_Nowak" <svv1999 hotmail.com> writes:
Don wrote:


 But that fact isn't clear from the docs.


Thx for the clarification.
-manfred
Nov 11 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/10 4:36 AM, Don wrote:

 Manfred_Nowak wrote:

 Don wrote:


 that's the only thing that is missing


 Disagreed.

 One of the main points of all languages is to emphasize ones aim,
 espacially if there is a chance of misinterpretation because of the
 language.

 Example: there is only a tiny change in the characters from `31415' to `
 3.1415'. Without function overloading this can be detected in D,
 because the type of actual parameters changes and Walter dismissed
 automatic type changes from `real' to `int'.

 The situation the OP described sams quite similar to me.
 -manfred


 I was replying to Rainer, not to the OP.
 At present in the compiler there is no difference between "a" "b" and
 "a" ~ "b". So implicit joining could be disallowed with loss of
 functionality. But that fact isn't clear from the docs.


Well the story is a tad longer. Associativity must be also taken into 
account. Consider:

string s = readText("/path/to/file");
writeln("The " ~ " text is: " ~ s ~ "\n" ~ " === " ~ "\n end.\n");

In this case, the compiler must look ahead to concatenate all literal 
strings in the expression before concatenating with s. Since ~ is just 
left-associative, then we have a special rule on our hands.

I think removing literal concatenation wouldn't harm. There is an 
unwritten rule in the back of my mind that a language should be designed 
such that inserting or removing a punctuation sign in a program does not 
change the semantics of the program. This may not be always attainable, 
but it's a good goal to live into. I remember this story about a 
mission-critical Fortran program blew up because of a punctuation 
character in the wrong place.

Regarding the dimension of this problem, I don't think there's a lot of 
evidence there. C and C++ have had implicit concatenation of string 
literals forever, but I've never read or heard anywhere about that issue 
being even on the radar.


Andrei
Nov 11 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 11 Nov 2010 10:03:58 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 11/11/10 4:36 AM, Don wrote:

 Manfred_Nowak wrote:

 Don wrote:


 that's the only thing that is missing


 Disagreed.

 One of the main points of all languages is to emphasize ones aim,
 espacially if there is a chance of misinterpretation because of the
 language.

 Example: there is only a tiny change in the characters from `31415' to  
 `
 3.1415'. Without function overloading this can be detected in D,
 because the type of actual parameters changes and Walter dismissed
 automatic type changes from `real' to `int'.

 The situation the OP described sams quite similar to me.
 -manfred


 I was replying to Rainer, not to the OP.
 At present in the compiler there is no difference between "a" "b" and
 "a" ~ "b". So implicit joining could be disallowed with loss of
 functionality. But that fact isn't clear from the docs.


 Well the story is a tad longer. Associativity must be also taken into  
 account. Consider:

 string s = readText("/path/to/file");
 writeln("The " ~ " text is: " ~ s ~ "\n" ~ " === " ~ "\n end.\n");

 In this case, the compiler must look ahead to concatenate all literal  
 strings in the expression before concatenating with s. Since ~ is just  
 left-associative, then we have a special rule on our hands.


Hm... testing it appears you are right -- the compiler folds "The " ~ "  
text is: " together, but not the elements after s.  Even with optimization  
turned on.

I would think it would, considering it should fold "abc" "def" currently.   
This means it already has to look ahead to see if "abc" is indeed the end  
of the literal.  Can't we just change that rule?  In other words, get rid  
of one special rule and replace it with another?

IMO, this is actually bad that the compiler does not fold concatenated  
string literals in all cases.  Don, maybe you can file a bug on that?


 Regarding the dimension of this problem, I don't think there's a lot of  
 evidence there. C and C++ have had implicit concatenation of string  
 literals forever, but I've never read or heard anywhere about that issue  
 being even on the radar.


Well, it's also the only way to concatenate literals together in C++/C.   
So even if there were complaints, there was a legitimate reason to keep  
it.  People tend not to complain as much when there are valid reasons to  
have something.  Compare that to if(x); where there is no valid reason to  
have it.

Give C++/C a way to concatenate literals together the way D can, and this  
might change.

But besides all that, it looks like a no-brainer to me -- we have  
equivalent syntax that works (or at least should work) the same, and the  
alternative syntax is not ambiguous and prone to error.

-Steve
Nov 11 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Rainer Deyke:


 Wait, what?  That's a static assert.  How can it both assert and compile
 with no errors?


You are right, what I meant is that if you remove the assert the program
compiles with no errors (also note the number 5 that is different from 4
strings):

enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
void main() {}



 In the latter case, 'f' receives an expression (which
 can be evaluated at compile time) as argument,


I meant the concatenation to be evaluated at compile-time for sure, so there is
zero runtime overhead.



 so the string may not be
 zero terminated.  This is a critical difference if 'f' is a (wrapper
 around a) C function.


I hope Don's idea on this (thank you Don) will be enough.

---------------------

Again, sorry for the tone of my original post of this thread.

Bye,
bearophile
Nov 11 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-11-10 23:51:38 -0500, Rainer Deyke <rainerd eldwood.com> said:


 As it turns out, the joining of adjacent strings is a critical feature.
  Consider the following:
   f("a" "b");
   f("a" ~ "b");
 These are /not/ equivalent.  In the former cases, 'f' receives a string
 literal as argument, which means that the string is guaranteed to be
 zero terminated.  In the latter case, 'f' receives an expression (which
 can be evaluated at compile time) as argument, so the string may not be
 zero terminated.  This is a critical difference if 'f' is a (wrapper
 around a) C function.


You worry too much. With 'f' a wrapper around a C function that takes a 
const(char)* argument, if the argument is not a literal string then it 
won't compile. Only string literals are implicitly convertible to 
const(char)*, not 'string' variables.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 11 2010
parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 11/11/2010 06:06, Michel Fortin wrote:

 On 2010-11-10 23:51:38 -0500, Rainer Deyke <rainerd eldwood.com> said:
 

 As it turns out, the joining of adjacent strings is a critical feature.
  Consider the following:
   f("a" "b");
   f("a" ~ "b");
 These are /not/ equivalent.  In the former cases, 'f' receives a string
 literal as argument, which means that the string is guaranteed to be
 zero terminated.  In the latter case, 'f' receives an expression (which
 can be evaluated at compile time) as argument, so the string may not be
 zero terminated.  This is a critical difference if 'f' is a (wrapper
 around a) C function.


 
 You worry too much. With 'f' a wrapper around a C function that takes a
 const(char)* argument, if the argument is not a literal string then it
 won't compile. Only string literals are implicitly convertible to
 const(char)*, not 'string' variables.


You just restated the problem.  There needs to be a way to break up
string literals while still treating them as a single string literal
that is convertible to 'const(char)*'.  You could overload binary '~'
for this, but I think this may be confusing.


-- 
Rainer Deyke - rainerd eldwood.com
Nov 11 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-11-11 15:05:08 -0500, Rainer Deyke <rainerd eldwood.com> said:


 On 11/11/2010 06:06, Michel Fortin wrote:

 On 2010-11-10 23:51:38 -0500, Rainer Deyke <rainerd eldwood.com> said:
 

 As it turns out, the joining of adjacent strings is a critical feature.
 Consider the following:
 f("a" "b");
 f("a" ~ "b");
 These are /not/ equivalent.  In the former cases, 'f' receives a string
 literal as argument, which means that the string is guaranteed to be
 zero terminated.  In the latter case, 'f' receives an expression (which
 can be evaluated at compile time) as argument, so the string may not be
 zero terminated.  This is a critical difference if 'f' is a (wrapper
 around a) C function.


 
 You worry too much. With 'f' a wrapper around a C function that takes a
 const(char)* argument, if the argument is not a literal string then it
 won't compile. Only string literals are implicitly convertible to
 const(char)*, not 'string' variables.


 
 You just restated the problem.  There needs to be a way to break up
 string literals while still treating them as a single string literal
 that is convertible to 'const(char)*'.  You could overload binary '~'
 for this, but I think this may be confusing.


Perhaps I misstated things a bit. Only *compile-time* strings are 
implicitly convertible to const(char)*. The expression "abc"~"def" is a 
string known at compile-time, and is written in the object file as one 
string literal.

Note that compile-time strings could also come from enums and 
templates. This will be written as one string literal in the object 
file:

	enum hello = "hello";
	template T(alias s) { enum T = s; }

	unittest {
		f(hello ~ T!"world");
	}

This call to 'f' works because hello~T!"world" forms a compile-time 
string and is implicitly convertible to a const(char)*. Try it! Also 
try changing 'enum' with 'auto' to make hello a variable and it'll no 
longer work.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 11 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 10 Nov 2010 21:34:07 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:


 Do you seen anything wrong in this code? It compiles with no errors:

 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}


 Yet that code asserts. it's an excellent example of why a sloppy  
 compiler/language sooner or later comes back to bite your ass.
 I've recently had another bug caused by automatic joining of adjacent  
 strings. I think this is the 3rd I have found in my D code. This is  
 enough.

 In C the joining of adjacent strings is sometimes useful, but explicit  
 is better than implicit, and D has a short and good operator to perform  
 joining of strings, the ~, and D strings are allowed to span multi-lines.


100% agree.  Get rid of it.  My suggestion is to make auto-concatenation  
an error and see how many unintended errors there are in phobos.  This  
model of testing has helped to explain how features are bug prone in the  
past.

-Steve

P.S. WRT bearophile's constant nagging, I agree it's not the best way to  
be heard.  But if you feel strongly about something, and it's not getting  
attention, I don't see another way.  Note that if you didn't continuously  
nag about stylistic issues that are very subjective, nagging about real  
problems like this would carry more weight.

I wrote a very similar post that resulted in the destruction of class ==  
null from the language (ironically, I think it could be inserted back into  
the language now that object.opEquals is called instead).
Nov 11 2010
prev sibling next sibling parent reply Gary Whatmore <no spam.sp> writes:
Yao G. Wrote:


 On Wed, 10 Nov 2010 20:34:07 -0600, bearophile <bearophileHUGS lycos.com>  
 wrote:
 

 Do you seen anything wrong in this code? It compiles with no errors:

 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}


 Yet that code asserts. it's an excellent example of why a sloppy  
 compiler/language sooner or later comes back to bite your ass.


 
 Stop blaming the compiler for your own carelessness.


I fully agree with this. It's odd to see only few people opposing this, because
the feature has no merit. If the language needs to be overly verbose in every
turn, bearophile could go and use Java instead.


 

 In C the joining of adjacent strings is sometimes useful, but explicit  
 is better than implicit, and D has a short and good operator to perform  
 joining of strings, the ~, and D strings are allowed to span multi-lines.


 
 I find it useful, and I like it. I like to break long strings into smaller  
 ones
 and put each one in one line. I know that you can do that using one single  
 string, but
 some syntax hightlighters don't like it that way.


Multiline strings have traditionally required stupid hacks. D might be the only
string oriented language with so many useful string literals. Very useful in
string processing.


 


 polished, and indeed it refuses automatic joining of adjacent strings:
 [...]
 This is one of the about twenty little/tiny changes I am waiting for D.


 



Or Java.

 

 So please kill automatic joining of adjacent strings in D with fire.


 
 No.


votes++
Nov 11 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 11 Nov 2010 08:26:40 -0500, Gary Whatmore <no spam.sp> wrote:


 Yao G. Wrote:


 On Wed, 10 Nov 2010 20:34:07 -0600, bearophile  
 <bearophileHUGS lycos.com>
 wrote:


 Do you seen anything wrong in this code? It compiles with no errors:

 enum string[5] data = ["green", "magenta", "blue" "red", "yellow"];
 static assert(data[4] == "yellow");
 void main() {}


 Yet that code asserts. it's an excellent example of why a sloppy
 compiler/language sooner or later comes back to bite your ass.


 Stop blaming the compiler for your own carelessness.


 I fully agree with this. It's odd to see only few people opposing this,  
 because the feature has no merit. If the language needs to be overly  
 verbose in every turn, bearophile could go and use Java instead.


The "feature" of concatenating two strings together automatically without  
any operator has no merit.  In C it was important because C does not have  
any other way to concatenate multiple strings together at compile-time.   
With the way the preprocessor works, it would be very difficult to  
concatenate string literals with macros.  But we don't have a preprocessor  
in D and D *does* have constant folding with the ~ operator.

This is a no brainer -- we need to kill auto string concatenation.  It  
serves no purpose, there is already a clear, concise, unambiguous  
alternative that fits exactly into the language grammar.

It's like the operator precedence of logical and comparison operators was  
a carryover from the B language.  I'm sooo glad we got rid of that.


 In C the joining of adjacent strings is sometimes useful, but explicit
 is better than implicit, and D has a short and good operator to  


 perform

 joining of strings, the ~, and D strings are allowed to span  


 multi-lines.

 I find it useful, and I like it. I like to break long strings into  
 smaller
 ones
 and put each one in one line. I know that you can do that using one  
 single
 string, but
 some syntax hightlighters don't like it that way.


 Multiline strings have traditionally required stupid hacks. D might be  
 the only string oriented language with so many useful string literals.  
 Very useful in string processing.


In this case, it's not a hack, it fits precisely within the definition of  
the language.  It's like saying:

1 +
2

is a 'hack' to get multi-line addition working.  How many times have you  
written:

if((condition1 && condition2) ||
    condition3 ||
    condition4 ||
    ...)

To keep your sanity when writing complex if statements?  Have you ever  
felt that adding those pesky || at the end of each line was a 'hack'?   
This is exactly the same thing.

-Steve
Nov 11 2010
parent Gary Whatmore <no spam.sp> writes:
Steven Schveighoffer Wrote:


 On Thu, 11 Nov 2010 08:26:40 -0500, Gary Whatmore <no spam.sp> wrote:

 Multiline strings have traditionally required stupid hacks. D might be  
 the only string oriented language with so many useful string literals.  
 Very useful in string processing.


 
 In this case, it's not a hack, it fits precisely within the definition of  
 the language.  It's like saying:
 
 1 +
 2
 
 is a 'hack' to get multi-line addition working.  How many times have you  
 written:
 
 if((condition1 && condition2) ||
     condition3 ||
     condition4 ||
     ...)
 
 To keep your sanity when writing complex if statements?  Have you ever  
 felt that adding those pesky || at the end of each line was a 'hack'?   
 This is exactly the same thing.


Good point. I got it now.
Nov 11 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Gary Whatmore wrote:

 Multiline strings have traditionally required stupid hacks.


Yeah, I always hated that. Why couldn't I just insert some multiline text and 
just put it in quotes? Naw, I have to laboriously quote each line separately. 
Ridiculous.
Nov 11 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Gary Whatmore:


 I fully agree with this. It's odd to see only few people opposing this,
because the feature has no merit. If the language needs to be overly verbose in
every turn, bearophile could go and use Java instead.


Is adding 1 char every time you use implicit joining of strings in your modules
"overly verbose"?



 I find it useful, and I like it. I like to break long strings into smaller  
 ones
 and put each one in one line. I know that you can do that using one single  
 string, but
 some syntax hightlighters don't like it that way.




This string of yours:

string someText = "I find it useful, and I like it. I like to break long
strings into smaller ones"
    "and put each one in one line. I know that you can do that using one single
string, but"
    "some syntax hightlighters don't like it that way.";

Now becomes:

string someText = "I find it useful, and I like it. I like to break long
strings into smaller ones" ~
    "and put each one in one line. I know that you can do that using one single
string, but" ~
    "some syntax hightlighters don't like it that way.";

Bye,
bearophile
Nov 11 2010
prev sibling next sibling parent klickverbot <see klickverbot.at> writes:
+1 on this.

While implicit joining can certainly be useful in C in some cases, D has 
the ~ operator for such cases.

Since compile-time primitives are guaranteed to be folded anyway (IIRC), 
I can imagine no situation where the benefits of banning implicit 
joining (reducing the chance for bugs, less special cases) would not 
outweigh the costs of an additional character to type.
Nov 11 2010
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Rainer Deyke Wrote:

 
 As it turns out, the joining of adjacent strings is a critical feature.
  Consider the following:
   f("a" "b");
   f("a" ~ "b");
 These are /not/ equivalent.


I would hope that the const folding mechanism would combine these at
compile-time.  There's effectively no difference between a constant and an
expression (without side-effects) that produces the same value.
Nov 11 2010
parent Rainer Deyke <rainerd eldwood.com> writes:
On 11/11/2010 13:37, Sean Kelly wrote:

 Rainer Deyke Wrote:

 
 As it turns out, the joining of adjacent strings is a critical
 feature. Consider the following: f("a" "b"); f("a" ~ "b"); These
 are /not/ equivalent.


 
 I would hope that the const folding mechanism would combine these at
 compile-time.


Of course it would.  That's not the issue.  The issue is, is a string
that's generated at compile-time guaranteed to be zero-terminated, the
way a string literal is?  Even if the same operation at run-time would
/not/ generate a zero-terminated string?


-- 
Rainer Deyke - rainerd eldwood.com
Nov 11 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):

- Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
- Don has not said how much he likes the idea, but he has shown no technical
opposition against it, and I think he may accept it.
- Sean Kelly sees no technical problems in the idea, and I think he accepts it.
- Steven Schveighoffer likes the idea.
- Vladimir Panteleev likes the idea.
- Manfred Nowak seems to like the idea.
- Michel Fortin seems to like this idea.
- Yao G. is opposed (but he has shown to not consider the usage of ~ to concat
lines).
- dennis luehring likes the idea.
- klickverbot agrees with the idea.
- Jonathan M Davis agrees with the idea.
- Rainer Deyke has suggested a problem that may be solved or doesn't exists.
- spir seems now more or less OK with the idea, but I am not sure.
- so seems a OK with the idea now, but I am not sure.
- I like this idea.
- Brad Roberts has expressed no opinion on the topic.

On average the answers seem positive. So, Walter are you willing to deprecate
automatic joining of adjacent strings (and later turn it into a syntax error,
the error message may suggest to add a ~)?

Bye,
bearophile
Nov 11 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/10 3:33 PM, bearophile wrote:

 Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):

 - Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
 - Don has not said how much he likes the idea, but he has shown no technical
opposition against it, and I think he may accept it.
 - Sean Kelly sees no technical problems in the idea, and I think he accepts it.
 - Steven Schveighoffer likes the idea.
 - Vladimir Panteleev likes the idea.
 - Manfred Nowak seems to like the idea.
 - Michel Fortin seems to like this idea.
 - Yao G. is opposed (but he has shown to not consider the usage of ~ to concat
lines).
 - dennis luehring likes the idea.
 - klickverbot agrees with the idea.
 - Jonathan M Davis agrees with the idea.
 - Rainer Deyke has suggested a problem that may be solved or doesn't exists.
 - spir seems now more or less OK with the idea, but I am not sure.
 - so seems a OK with the idea now, but I am not sure.
 - I like this idea.
 - Brad Roberts has expressed no opinion on the topic.

 On average the answers seem positive. So, Walter are you willing to deprecate
automatic joining of adjacent strings (and later turn it into a syntax error,
the error message may suggest to add a ~)?


Let me ask a related question: if there were a priority list of things 
that Walter should be busy with, where would this feature be on that list?

Andrei
Nov 11 2010
next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
Freshly added to the normal-priority queue!
Thank goodness.

On Thu, Nov 11, 2010 at 6:11 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/11/10 3:33 PM, bearophile wrote:


 Now this discussion seems settled enough, so I may summarize its results a
 little (please fix this list if you see an error):

 - Andrei Alexandrescu has said this idea doesn't harm but he sees not much
 evidence this is a problem in C/C++.
 - Don has not said how much he likes the idea, but he has shown no
 technical opposition against it, and I think he may accept it.
 - Sean Kelly sees no technical problems in the idea, and I think he
 accepts it.
 - Steven Schveighoffer likes the idea.
 - Vladimir Panteleev likes the idea.
 - Manfred Nowak seems to like the idea.
 - Michel Fortin seems to like this idea.
 - Yao G. is opposed (but he has shown to not consider the usage of ~ to
 concat lines).
 - dennis luehring likes the idea.
 - klickverbot agrees with the idea.
 - Jonathan M Davis agrees with the idea.
 - Rainer Deyke has suggested a problem that may be solved or doesn't
 exists.
 - spir seems now more or less OK with the idea, but I am not sure.
 - so seems a OK with the idea now, but I am not sure.
 - I like this idea.
 - Brad Roberts has expressed no opinion on the topic.

 On average the answers seem positive. So, Walter are you willing to
 deprecate automatic joining of adjacent strings (and later turn it into a
 syntax error, the error message may suggest to add a ~)?


 Let me ask a related question: if there were a priority list of things that
 Walter should be busy with, where would this feature be on that list?

 Andrei
Nov 11 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 Let me ask a related question: if there were a priority list of things 
 that Walter should be busy with, where would this feature be on that list?


I don't know, I think you and Walter are able to judge the relative priorities
of things. In Bugzilla I have about twenty small/tiny breaking changes like
this one, some of them are probably already virtually closed. This specific one
was sleeping for few months there. If you want to change little but non
backwards compatible things in D2 (like disallowing implicit concatenation of
strings) you need to do it sooner, because when all people have written lot of
D2 code you can't remove/change features any more. So while this bug report is
much less important than additive features like for example named function
arguments, it has higher priority, because named arguments may be added later,
in D3. Seeing how those bug reports are getting dust, I'd like to show them
here one by one (because I have shown them all together already, with no
answers), so they may receive some attention, like this one. One year from now
most or all those very small enhancement requests will probably be useless, and
worth closing as WONTFIX with a message like "it's too much late to change
this". I'm doing my best to help remove some warts from D2.

Bye,
bearophile
Nov 11 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Let me ask a related question: if there were a priority list of things 
 that Walter should be busy with, where would this feature be on that list?


For once, I agree with Bearophile. The adjacent string concatenation was a very 
very early feature, and the ~ completely supplants it. While I don't think it 
causes many problems, it's a pointless redundancy and should be removed.
Nov 11 2010
next sibling parent Marianne Gagnon <auria.mg gmail.com> writes:
 For once, I agree with Bearophile. The adjacent string concatenation was a
very 
 very early feature, and the ~ completely supplants it. While I don't think it 
 causes many problems, it's a pointless redundancy and should be removed.


Agreed; it seems to be a minor change, and the issue of code compatibility is a
guenine one, the later such changes are done, the more code breakage occurs.

So receive my humble +1 :)

-- Auria
Nov 11 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/10 5:59 PM, Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Let me ask a related question: if there were a priority list of things
 that Walter should be busy with, where would this feature be on that
 list?


 For once, I agree with Bearophile. The adjacent string concatenation was
 a very very early feature, and the ~ completely supplants it. While I
 don't think it causes many problems, it's a pointless redundancy and
 should be removed.


I agree too but there are many similarly good ideas (some of which from 
himself) that are older.

Andrei
Nov 11 2010
parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 On 11/11/10 5:59 PM, Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Let me ask a related question: if there were a priority list of things
 that Walter should be busy with, where would this feature be on that
 list?


 For once, I agree with Bearophile. The adjacent string concatenation was
 a very very early feature, and the ~ completely supplants it. While I
 don't think it causes many problems, it's a pointless redundancy and
 should be removed.


 
 I agree too but there are many similarly good ideas (some of which from 
 himself) that are older.
 
 Andrei


This isn't new. I remember this one being discussed about seven years ago.
Nov 12 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 1:06 AM, Don wrote:

 Andrei Alexandrescu wrote:

 On 11/11/10 5:59 PM, Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Let me ask a related question: if there were a priority list of things
 that Walter should be busy with, where would this feature be on that
 list?


 For once, I agree with Bearophile. The adjacent string concatenation was
 a very very early feature, and the ~ completely supplants it. While I
 don't think it causes many problems, it's a pointless redundancy and
 should be removed.


 I agree too but there are many similarly good ideas (some of which
 from himself) that are older.

 Andrei


 This isn't new. I remember this one being discussed about seven years ago.


Well put me on board then. Walter, please don't forget to tweak the 
associativity rules: var ~ " literal " ~ " literal " concatenates 
literals first.

Andrei
Nov 12 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Nov 2010 04:53:23 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 11/12/10 1:06 AM, Don wrote:

 Andrei Alexandrescu wrote:

 On 11/11/10 5:59 PM, Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Let me ask a related question: if there were a priority list of  
 things
 that Walter should be busy with, where would this feature be on that
 list?


 For once, I agree with Bearophile. The adjacent string concatenation  
 was
 a very very early feature, and the ~ completely supplants it. While I
 don't think it causes many problems, it's a pointless redundancy and
 should be removed.


 I agree too but there are many similarly good ideas (some of which
 from himself) that are older.

 Andrei


 This isn't new. I remember this one being discussed about seven years  
 ago.


 Well put me on board then. Walter, please don't forget to tweak the  
 associativity rules: var ~ " literal " ~ " literal " concatenates  
 literals first.


You mean *should* concatenate literals first?  I think currently it  
doesn't.

-Steve
Nov 12 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 4:41 AM, Steven Schveighoffer wrote:

 On Fri, 12 Nov 2010 04:53:23 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 11/12/10 1:06 AM, Don wrote:

 Andrei Alexandrescu wrote:

 On 11/11/10 5:59 PM, Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Let me ask a related question: if there were a priority list of
 things
 that Walter should be busy with, where would this feature be on that
 list?


 For once, I agree with Bearophile. The adjacent string
 concatenation was
 a very very early feature, and the ~ completely supplants it. While I
 don't think it causes many problems, it's a pointless redundancy and
 should be removed.


 I agree too but there are many similarly good ideas (some of which
 from himself) that are older.

 Andrei


 This isn't new. I remember this one being discussed about seven years
 ago.


 Well put me on board then. Walter, please don't forget to tweak the
 associativity rules: var ~ " literal " ~ " literal " concatenates
 literals first.


 You mean *should* concatenate literals first? I think currently it doesn't.

 -Steve


Yah, "shall" as they say in Standardese :o). Currently it doesn't, but 
you get to catenate literals by juxtaposition. For example, this expression:

s ~ "def" "ghi"

when naively changed to

s ~ "def" ~ "ghi"

will do more work than before. We must avoid that.


Andrei
Nov 12 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 will do more work than before. We must avoid that.


I have added a note at the bottom of the relative bug report.

Bye,
bearophile
Nov 12 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 12/11/2010 09:53, Andrei Alexandrescu wrote:
<snip>

 Well put me on board then. Walter, please don't forget to tweak the
 associativity rules: var ~ " literal " ~ " literal " concatenates
 literals first.


You mean make ~ right-associative?  I think this'll break more code than 
it fixes.

But implementing a compiler optimisation so that var ~ ctc ~ ctc is 
processed as var ~ (ctc ~ ctc), _in those cases where they're 
equivalent_, would be sensible.

ctc = compile-time constant

Stewart.
Nov 13 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:


 You mean make ~ right-associative?  I think this'll break more code than 
 it fixes.
 
 But implementing a compiler optimisation so that var ~ ctc ~ ctc is 
 processed as var ~ (ctc ~ ctc), _in those cases where they're 
 equivalent_, would be sensible.
 
 ctc = compile-time constant
 
 Stewart.


It may be good to add that comment here, if you want I may add it myself:
http://d.puremagic.com/issues/show_bug.cgi?id=3827

Bye,
bearophile
Nov 13 2010
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Stewart Gordon wrote:

 On 12/11/2010 09:53, Andrei Alexandrescu wrote:
 <snip>

 Well put me on board then. Walter, please don't forget to tweak the
 associativity rules: var ~ " literal " ~ " literal " concatenates
 literals first.


=20
 You mean make ~ right-associative?  I think this'll break more code tha=


n

 it fixes.
=20


	No because making ~ right-associative would cause the reverse
problem: ctc ~ ctc ~ var would not work. What is needed is for ctc ~
ctc ~ var ~ ctc ~ ctc to be processed as ((ctc ~ ctc) ~ var) ~ (ctc
~ ctc).


 ctc =3D compile-time constant
=20


		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Nov 14 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Stewart Gordon wrote:

 On 12/11/2010 09:53, Andrei Alexandrescu wrote:
 <snip>

 Well put me on board then. Walter, please don't forget to tweak the
 associativity rules: var ~ " literal " ~ " literal " concatenates
 literals first.


 
 You mean make ~ right-associative?  I think this'll break more code than 
 it fixes.
 
 But implementing a compiler optimisation so that var ~ ctc ~ ctc is 
 processed as var ~ (ctc ~ ctc), _in those cases where they're 
 equivalent_, would be sensible.


Andrei's right. This is not about making it right-associative. It is about 
defining in the language that:

    ((a ~ b) ~ c)

is guaranteed to produce the same result as:

    (a ~ (b ~ c))

Unfortunately, the language cannot make such a guarantee in the face of
operator 
overloading. But it can do it for cases where operator overloading is not in
play.
Nov 19 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/11/2010 05:31, Walter Bright wrote:

 Stewart Gordon wrote:

 On 12/11/2010 09:53, Andrei Alexandrescu wrote:
 <snip>

 Well put me on board then. Walter, please don't forget to tweak the
 associativity rules: var ~ " literal " ~ " literal " concatenates
 literals first.


 You mean make ~ right-associative? I think this'll break more code
 than it fixes.

 But implementing a compiler optimisation so that var ~ ctc ~ ctc is
 processed as var ~ (ctc ~ ctc), _in those cases where they're
 equivalent_, would be sensible.


 Andrei's right. This is not about making it right-associative. It is
 about defining in the language that:

 ((a ~ b) ~ c)

 is guaranteed to produce the same result as:

 (a ~ (b ~ c))

 Unfortunately, the language cannot make such a guarantee in the face of
 operator overloading. But it can do it for cases where operator
 overloading is not in play.


So if you have the code:
  (a ~ b ~ c)
and b and c are strings, but a is not a string (nor has a toString 
method, nor implicit convertion), but has a overload of the append 
operator, then b and c will not be joined in compile-time, according to 
that?

-- 
Bruno Medeiros - Software Engineer
Nov 29 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/29/10 3:38 PM, Bruno Medeiros wrote:

 On 20/11/2010 05:31, Walter Bright wrote:

 Stewart Gordon wrote:

 On 12/11/2010 09:53, Andrei Alexandrescu wrote:
 <snip>

 Well put me on board then. Walter, please don't forget to tweak the
 associativity rules: var ~ " literal " ~ " literal " concatenates
 literals first.


 You mean make ~ right-associative? I think this'll break more code
 than it fixes.

 But implementing a compiler optimisation so that var ~ ctc ~ ctc is
 processed as var ~ (ctc ~ ctc), _in those cases where they're
 equivalent_, would be sensible.


 Andrei's right. This is not about making it right-associative. It is
 about defining in the language that:

 ((a ~ b) ~ c)

 is guaranteed to produce the same result as:

 (a ~ (b ~ c))

 Unfortunately, the language cannot make such a guarantee in the face of
 operator overloading. But it can do it for cases where operator
 overloading is not in play.


 So if you have the code:
 (a ~ b ~ c)
 and b and c are strings, but a is not a string (nor has a toString
 method, nor implicit convertion), but has a overload of the append
 operator, then b and c will not be joined in compile-time, according to
 that?


That is correct. The compiler cannot infer that user-defined ~ is in 
fact associative.

Andrei
Nov 29 2010
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
 Let me ask a related question: if there were a priority list of things
 that Walter should be busy with, where would this feature be on that list?


i think bearophil just tries to install an community-decision-process 
and the first post of this thread seems to feel right, all other 
dicussions ended "without" any result for the commmunity

what about a process like that

bearophile(and others) throws in an idea, dicuss it to the "end"
and then comes an small aproval(summery) post like the first one here - 
after that all involed people should just say yes/no, and after that it 
should be clear if walter (as happend here) does like the idea and want 
to work on it (when time comes), but then it can be put on an more 
"official" wishlist - and think many of bearophils idea will get on this 
list

this list is got then a prio from walter, and you and the others...

D isn't missing of good ideas, missing library features etc. - we need
an aproval process
Nov 12 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 11 Nov 2010 19:11:54 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 11/11/10 3:33 PM, bearophile wrote:

 Now this discussion seems settled enough, so I may summarize its  
 results a little (please fix this list if you see an error):

 - Andrei Alexandrescu has said this idea doesn't harm but he sees not  
 much evidence this is a problem in C/C++.
 - Don has not said how much he likes the idea, but he has shown no  
 technical opposition against it, and I think he may accept it.
 - Sean Kelly sees no technical problems in the idea, and I think he  
 accepts it.
 - Steven Schveighoffer likes the idea.
 - Vladimir Panteleev likes the idea.
 - Manfred Nowak seems to like the idea.
 - Michel Fortin seems to like this idea.
 - Yao G. is opposed (but he has shown to not consider the usage of ~ to  
 concat lines).
 - dennis luehring likes the idea.
 - klickverbot agrees with the idea.
 - Jonathan M Davis agrees with the idea.
 - Rainer Deyke has suggested a problem that may be solved or doesn't  
 exists.
 - spir seems now more or less OK with the idea, but I am not sure.
 - so seems a OK with the idea now, but I am not sure.
 - I like this idea.
 - Brad Roberts has expressed no opinion on the topic.

 On average the answers seem positive. So, Walter are you willing to  
 deprecate automatic joining of adjacent strings (and later turn it into  
 a syntax error, the error message may suggest to add a ~)?


 Let me ask a related question: if there were a priority list of things  
 that Walter should be busy with, where would this feature be on that  
 list?


Depends.  If it's easy to fix, bang it out.  If it's more involved, it  
should be low.  I don't see this as a heavy hitter.

I'd *much* rather see inout fixed.

-Steve
Nov 12 2010
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 12.11.2010 00:33, schrieb bearophile:

 Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):

 - Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
 - Don has not said how much he likes the idea, but he has shown no technical
opposition against it, and I think he may accept it.
 - Sean Kelly sees no technical problems in the idea, and I think he accepts it.
 - Steven Schveighoffer likes the idea.
 - Vladimir Panteleev likes the idea.
 - Manfred Nowak seems to like the idea.
 - Michel Fortin seems to like this idea.
 - Yao G. is opposed (but he has shown to not consider the usage of ~ to concat
lines).
 - dennis luehring likes the idea.
 - klickverbot agrees with the idea.
 - Jonathan M Davis agrees with the idea.
 - Rainer Deyke has suggested a problem that may be solved or doesn't exists.
 - spir seems now more or less OK with the idea, but I am not sure.
 - so seems a OK with the idea now, but I am not sure.
 - I like this idea.
 - Brad Roberts has expressed no opinion on the topic.

 On average the answers seem positive. So, Walter are you willing to deprecate
automatic joining of adjacent strings (and later turn it into a syntax error,
the error message may suggest to add a ~)?

 Bye,
 bearophile


thanks bearopile, i think you made the first step installing an maybe 
good working idea approval process - let people throw together their 
pros and cons, and then post an was-that-your-opinion-message
that could ease the decision process for walter,andrei etc. alot - and 
you can tell others that walter,andrei,ect..... agreed with you're idea 
- that stops re-dicussions

but the information,results must be published in an more official way 
digitalmars.com/d/reviews.html or something like that, not an hidden 
wiki-page somewhere or an personal page like the inoffical wishlist
Nov 12 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/11/2010 23:33, bearophile wrote:

 Now this discussion seems settled enough, so I may summarize its results a
little (please fix this list if you see an error):

 - Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.
 - Don has not said how much he likes the idea, but he has shown no technical
opposition against it, and I think he may accept it.
 - Sean Kelly sees no technical problems in the idea, and I think he accepts it.
 - Steven Schveighoffer likes the idea.
 - Vladimir Panteleev likes the idea.
 - Manfred Nowak seems to like the idea.
 - Michel Fortin seems to like this idea.
 - Yao G. is opposed (but he has shown to not consider the usage of ~ to concat
lines).
 - dennis luehring likes the idea.
 - klickverbot agrees with the idea.
 - Jonathan M Davis agrees with the idea.
 - Rainer Deyke has suggested a problem that may be solved or doesn't exists.
 - spir seems now more or less OK with the idea, but I am not sure.
 - so seems a OK with the idea now, but I am not sure.
 - I like this idea.
 - Brad Roberts has expressed no opinion on the topic.

 On average the answers seem positive. So, Walter are you willing to deprecate
automatic joining of adjacent strings (and later turn it into a syntax error,
the error message may suggest to add a ~)?

 Bye,
 bearophile


For the record, I am also okay with the idea. (mostly because it 
simplifies the language). But like Andrei mentioned, the importance of 
this is so, so minor. Fortunately the implementation effort is also very 
low, so let's just check there is no unintended consequences, and move on.

-- 
Bruno Medeiros - Software Engineer
Nov 29 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:


 - Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.


Well, scope classes aren't more harmful than this.
Nov 12 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/10 12:03 AM, Kagamin wrote:

 bearophile Wrote:


 - Andrei Alexandrescu has said this idea doesn't harm but he sees not much
evidence this is a problem in C/C++.


 Well, scope classes aren't more harmful than this.


I think there's really no comparison there.

Andrei
Nov 12 2010