http://d.puremagic.com/issues/show_bug.cgi?id=3827



--- Comment #20 from bearophile_hugs@eml.cc 2010-11-16 19:38:56 PST ---
(In reply to comment #19)
> (In reply to comment #17)
> > Not that there's any real use case for "this" "that" anyway.  And those rare use cases
> 
> I use automatic joining all the time for long string literals. I want them to
> span multiple source lines without containing line breaks.
> No, not a rarely used feature.


Stewart Gordon was just talking about code like:
a ~ "this" "that"
where a is a string[].


To join multiple lines you may add a ~ at their end:

string text = "I use automatic joining all the time for long string literals. I
want them to " ~
              "span multiple source lines without containing line breaks. " ~
              "No, not a rarely used feature.";

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3827


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #21 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-11-16 21:33:05 PST ---
(In reply to comment #17)
> (In reply to comment #5)
> > The error message for the missing ~ can be something like this (adapted from the "'l' suffix is deprecated, use 'L' instead" error message generated by the usage of a 10l long literal):
> > 
> > adjacent string literals concatenation is deprecated, add ~ between them instead.
> 
> Better watch out for cases where just adding ~ changes the behaviour.
> 
> For example, if a is a string[], then a ~ "this" "that" and a ~ "this" ~ "that" evaluate to different strings.

doesn't this solve that problem? a ~ ("this" ~ "that")

BTW, I don't expect very many cases like this (in fact, I bet there are none).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3827



--- Comment #22 from Stewart Gordon <smjg@iname.com> 2010-11-17 03:58:08 PST ---
(In reply to comment #21)
> doesn't this solve that problem? a ~ ("this" ~ "that")

It does.  My point was that somebody might accidentally not add the brackets.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3827



--- Comment #23 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-11-17 12:04:03 PST ---
If constfold can access a's type, it can make the right decision.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3827



--- Comment #24 from bearophile_hugs@eml.cc 2010-11-22 12:01:40 PST ---
A recent note by Walter:

> 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3827



--- Comment #25 from bearophile_hugs@eml.cc 2011-03-20 04:29:08 PDT ---
See also:

http://stackoverflow.com/questions/2504536/why-allow-concatenation-of-string-literals

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3827



--- Comment #26 from bearophile_hugs@eml.cc 2012-03-10 17:31:34 PST ---
An example of the problems this avoids:http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=22649

Andrej Mitrovic:

> I see you are not the only one who started writing string array literals like this:
> 
> enum PEGCode = grammarCode!(
>      "Grammar <- S Definition+ EOI"
>     ,"Definition <- RuleName Arrow Expression"
>     ,"RuleName   <- Identifier>(ParamList?)"
>     ,"Expression <- Sequence (OR Sequence)*"
> );
> 
> IOW comma on the left side. I know it's not a style preference but
> actually a (unfortunate but needed) technique for avoiding bugs. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3827


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #27 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-03-10 17:56:16 PST ---
(In reply to comment #26)
> > enum PEGCode = grammarCode!(
> >      "Grammar <- S Definition+ EOI"
> >     ,"Definition <- RuleName Arrow Expression"
> >     ,"RuleName   <- Identifier>(ParamList?)"
> >     ,"Expression <- Sequence (OR Sequence)*"
> > );

Note that this is Philippe Sigaud's code. So you can him, and me to the list of people affected by this.

I'm doing string processing in D on a day-to-day basis, and whenever I have a list of strings I eventually end up shooting myself in the foot because of a missing comma. It's very easy (at least for clumsy me) to make the mistake. E.g. writing some headers to ignore:

string[] ignoredHeaders = [
    "foo.bar"  // todo: have to fix this later
    "foo.do",  // todo: later
];

When I have comments next to the strings it makes it easy to miss the missing comma, especially if the strings are of a different length.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------