Kill implicit joining of adjacent strings

[Steven Schveighoffer]

On Thu, 11 Nov 2010 10:03:58 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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