Kill implicit joining of adjacent strings

[Andrei Alexandrescu]

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