The following code compiles:

import std.stdio;

void main() {

	auto text = "Hello world!";
	if (!std.algorithm.endsWith(text, "!" ".")) {
		writeln("No punctuation!");
	} else {
		writeln("Has punctuation");
	}
}

The bug is in line 6 a missing comma between "!" and ".":

!std.algorithm.endsWith(text, "!" ".")

If you insert the comma, it will behave as expected.

Is this ok or a bug?

On Monday, 21 October 2013 at 15:12:36 UTC, Chris wrote:
> The following code compiles:
>
> import std.stdio;
>
> void main() {
>
> 	auto text = "Hello world!";
> 	if (!std.algorithm.endsWith(text, "!" ".")) {
> 		writeln("No punctuation!");
> 	} else {
> 		writeln("Has punctuation");
> 	}
> }
>
> The bug is in line 6 a missing comma between "!" and ".":
>
> !std.algorithm.endsWith(text, "!" ".")
>
> If you insert the comma, it will behave as expected.
>
> Is this ok or a bug?

It's a feature.

On Monday, 21 October 2013 at 15:12:36 UTC, Chris wrote:
> The following code compiles:
>
> import std.stdio;
>
> void main() {
>
> 	auto text = "Hello world!";
> 	if (!std.algorithm.endsWith(text, "!" ".")) {
> 		writeln("No punctuation!");
> 	} else {
> 		writeln("Has punctuation");
> 	}
> }
>
> The bug is in line 6 a missing comma between "!" and ".":
>
> !std.algorithm.endsWith(text, "!" ".")
>
> If you insert the comma, it will behave as expected.
>
> Is this ok or a bug?

It C-compatible behavior, two string literal separated with only spaces are concatenated into one. So your code was essentially `endsWith(text, "!.")`

Chris:

> Is this ok or a bug?

In my opinion it's a design bug inherited from C/C++ languages. Please vote for this issue:

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

Walter once agreed to remove this anti-feature.

Bye,
bearophile

On Monday, 21 October 2013 at 15:21:21 UTC, bearophile wrote:
> Chris:
>
>> Is this ok or a bug?
>
> In my opinion it's a design bug inherited from C/C++ languages. Please vote for this issue:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3827
>
> Walter once agreed to remove this anti-feature.
>
> Bye,
> bearophile

Hm. It took me a few minutes to find the bug in my program. I don't know yet what to think of it. If I wanted "!." I would possibly type this. Is there any real world scenario where this behavior could be useful?

On Monday, 21 October 2013 at 15:26:17 UTC, Chris wrote:
> Hm. It took me a few minutes to find the bug in my program. I don't know yet what to think of it. If I wanted "!." I would possibly type this. Is there any real world scenario where this behavior could be useful?

It was necessary in C because it does not have built-in string concatenation. So only way to define pre-formatted string was something like this: `"Error in " __FILENAME__ ", run for your lives!"`

It does not seem that needed in D. I was using it out of habit but bearophile has convinced me it is a bad idea.

On Monday, 21 October 2013 at 15:18:18 UTC, monarch_dodra wrote:
>
> It's a feature.

I actually like that feature. It's me compose long strings in an easily viewable way without having to use concatenation and therefore additional allocation. Or, even to just comment on indvidual lines

string command =
     "/usr/bin/rm -rf / " // Don't worry, it'll be fine...
     ">/dev/null 2>/dev/null" // This way nobody will know about it.

On Monday, 21 October 2013 at 15:38:47 UTC, David Eagen wrote:
> On Monday, 21 October 2013 at 15:18:18 UTC, monarch_dodra wrote:
>>
>> It's a feature.
>
> I actually like that feature. It's me compose long strings in an easily viewable way without having to use concatenation and therefore additional allocation. Or, even to just comment on indvidual lines
>
> string command =
>      "/usr/bin/rm -rf / " // Don't worry, it'll be fine...
>      ">/dev/null 2>/dev/null" // This way nobody will know about it.

Well, in my program it was a bug that could comfortably hide for quite a while. It didn't really matter until now, because the program worked in spite of the bug. Only recent changes (today) brought it to light. If it does more harm than good, than it should be removed. It's too easy to forget a comma in an array or in a function like endsWith. What is more, this type of bug might only become apparent after a long long time. If you have

auto list = ["Joseph", "Mary", "Peter", "Ustinov", "Django" "Pope"];

and Django and Pope are the least likely go be selected, it can take a while until you realize that there's a bug. For my part, I've lived happily without this feature.

On Monday, 21 October 2013 at 15:38:47 UTC, David Eagen wrote:
> I actually like that feature. It's me compose long strings in an easily viewable way without having to use concatenation and therefore additional allocation.

Concatenation of string literals doesn't need to allocate, as discussed here: http://d.puremagic.com/issues/show_bug.cgi?id=3827. It's trivial to handle the cases where you would've written "string1" "string2" instead of "string1" ~ "string2". Once overloaded operators come into play, it's a bit trickier, but if this case really occurred in your program, you could always add a pair of parens to fix it.

See also this post by Walter: http://forum.dlang.org/post/ibi742$gi2$1@digitalmars.com

David

On Monday, 21 October 2013 at 15:57:14 UTC, David Nadlinger wrote:
> Concatenation of string literals doesn't need to allocate, as discussed here: http://d.puremagic.com/issues/show_bug.cgi?id=3827. It's trivial to handle the cases where you would've written "string1" "string2" instead of "string1" ~ "string2". Once overloaded operators come into play, it's a bit trickier, but if this case really occurred in your program, you could always add a pair of parens to fix it.
>
> See also this post by Walter: http://forum.dlang.org/post/ibi742$gi2$1@digitalmars.com

Thanks for pointing that out. I've changed my stance then. It's causing difficult to find bugs and serves no useful purpose so it should go.

But since the thread you linked to is three years old it is apparently already decided and merely waiting implementation.