Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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: 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
Re: Kill implicit joining of adjacent strings
On 20/11/2010 05:31, Walter Bright wrote: Stewart Gordon wrote: On 12/11/2010 09:53, Andrei Alexandrescu wrote: 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
Re: Kill implicit joining of adjacent strings
Stewart Gordon wrote: On 12/11/2010 09:53, Andrei Alexandrescu wrote: 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.
Re: Kill implicit joining of adjacent strings
Stewart Gordon wrote: > On 12/11/2010 09:53, Andrei Alexandrescu wrote: > >> 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. > 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 = compile-time constant > Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
On 12/11/2010 09:53, Andrei Alexandrescu wrote: 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.
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
On 11/12/10 4:41 AM, Steven Schveighoffer wrote: On Fri, 12 Nov 2010 04:53:23 -0500, Andrei Alexandrescu 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
Re: Kill implicit joining of adjacent strings
On Thu, 11 Nov 2010 19:11:54 -0500, Andrei Alexandrescu 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
Re: Kill implicit joining of adjacent strings
On Fri, 12 Nov 2010 04:53:23 -0500, Andrei Alexandrescu 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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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.
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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.
Re: Kill implicit joining of adjacent strings
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 - rain...@eldwood.com
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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.
Re: Kill implicit joining of adjacent strings
> 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
Re: Kill implicit joining of adjacent strings
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.
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
Freshly added to the normal-priority queue! Thank goodness. On Thu, Nov 11, 2010 at 6:11 PM, Andrei Alexandrescu < seewebsiteforem...@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 >
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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.
Re: Kill implicit joining of adjacent strings
On 2010-11-11 15:05:08 -0500, Rainer Deyke said:
On 11/11/2010 06:06, Michel Fortin wrote:
On 2010-11-10 23:51:38 -0500, Rainer Deyke 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.for...@michelf.com
http://michelf.com/
Re: Kill implicit joining of adjacent strings
On 11/11/2010 06:06, Michel Fortin wrote:
> On 2010-11-10 23:51:38 -0500, Rainer Deyke 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 - rain...@eldwood.com
Re: Kill implicit joining of adjacent strings
+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.
Re: Kill implicit joining of adjacent strings
On Thu, 11 Nov 2010 10:03:58 -0500, Andrei Alexandrescu
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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
Am 11.11.2010 14:28, schrieb spir: On Thu, 11 Nov 2010 11:18:19 +0100 dennis luehring wrote: Am 11.11.2010 11:16, schrieb spir: > On Wed, 10 Nov 2010 23:10:35 -0500 > bearophile 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
Re: Kill implicit joining of adjacent strings
Steven Schveighoffer Wrote: > On Thu, 11 Nov 2010 08:26:40 -0500, Gary Whatmore 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.
Re: Kill implicit joining of adjacent strings
On Thu, 11 Nov 2010 08:26:40 -0500, Gary Whatmore wrote:
Yao G. Wrote:
On Wed, 10 Nov 2010 20:34:07 -0600, 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.
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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
Yao G. Wrote:
> On Wed, 10 Nov 2010 20:34:07 -0600, 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.
>
> 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.
>
> > Despite Walter seems to ignore C#, C# is a very well designed language,
> > 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.
>
> Maybe you should switch to C# :)
Or Java.
>
> > So please kill automatic joining of adjacent strings in D with fire.
>
> No.
votes++
Re: Kill implicit joining of adjacent strings
On Thu, 11 Nov 2010 11:18:19 +0100 dennis luehring wrote: > Am 11.11.2010 11:16, schrieb spir: > > On Wed, 10 Nov 2010 23:10:35 -0500 > > bearophile 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. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Kill implicit joining of adjacent strings
On 2010-11-10 23:51:38 -0500, Rainer Deyke 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.for...@michelf.com
http://michelf.com/
Re: Kill implicit joining of adjacent strings
Don wrote: > But that fact isn't clear from the docs. Thx for the clarification. -manfred
Re: Kill implicit joining of adjacent strings
On Wed, 10 Nov 2010 21:34:07 -0500, 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.
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).
Re: Kill implicit joining of adjacent strings
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.
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
Am 11.11.2010 11:16, schrieb spir: On Wed, 10 Nov 2010 23:10:35 -0500 bearophile 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
Re: Kill implicit joining of adjacent strings
On Wed, 10 Nov 2010 23:10:35 -0500 bearophile 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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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.
Re: Kill implicit joining of adjacent strings
On Thu, 11 Nov 2010 06:51:38 +0200, 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.
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,
Vladimirmailto:vladi...@thecybershadow.net
Re: Kill implicit joining of adjacent strings
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 - rain...@eldwood.com
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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/
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
"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/
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
On Thu, 11 Nov 2010 04:34:07 +0200, bearophile 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, Vladimirmailto:vladi...@thecybershadow.net
Re: Kill implicit joining of adjacent strings
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
Re: Kill implicit joining of adjacent strings
On Wed, 10 Nov 2010 20:34:07 -0600, 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.
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.
Despite Walter seems to ignore C#, C# is a very well designed language,
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.
Maybe you should switch to C# :)
So please kill automatic joining of adjacent strings in D with fire.
No.
Thank you,
bearophile
--
Yao G.
Re: Kill implicit joining of adjacent strings
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
>
> Despite Walter seems to ignore C#, C# is a very well designed language,
> polished, and indeed it refuses automatic joining of adjacent strings:
>
> public class Test {
> public static void Main() {
> string s = "hello " "world";
> }
> }
>
> That C# code gives the error:
>
> 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
