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
