In dco source code I have found:

void ShowUsage()
{
writeln("
dco build tool " ~ strVersion ~ "
written by FrankLIKE.
Usage:
dco [<switches...>] <files...>
for example: dco
or: dco app.d
build for dfl2: dco
....
}

I do not see here any "\n". Why this code is output all one by line, and not in single line?

Why my code:
writeln("App name:" ~ appName ~
"App version:" ~ appVersion ~
"To see help please use -h\\-help option");
writeln(args);

output:
App name:CoolAppApp version:0.0.1To see help please use -h\-help option[".\\app1
.exe"]

On Thursday, 20 November 2014 at 08:28:11 UTC, Suliman wrote:
> In dco source code I have found:
>
> void ShowUsage()
> {
> writeln("
> dco build tool " ~ strVersion ~ "
> written by FrankLIKE.
> Usage:
> dco [<switches...>] <files...>
> for example: dco
> or: dco app.d
> build for dfl2: dco
> ....
> }
>
> I do not see here any "\n". Why this code is output all one by line, and not in single line?
>
> Why my code:
> writeln("App name:" ~ appName ~
> "App version:" ~ appVersion ~
> "To see help please use -h\\-help option");
> writeln(args);
>
> output:
> App name:CoolAppApp version:0.0.1To see help please use -h\-help option[".\\app1
> .exe"]

"In all string literal forms, an EndOfLine is regarded as a single \n character."

http://dlang.org/lex.html



It's by design but is *really* annoying and should be limited to WysiwygString literals IMO.

Auto-formatting with clang-format or astyle can mess up writeln formatting completely.

Cheers,
uri

uri:

> It's by design

And it's a nice handy design.

Bye,
bearophile

I understand it.

I expect what concatenation symbol will stay new line in new line and not append it's to current:

	writeln(
	"first string"
	"second" ~
	"string"
	);

I expect:
first string
second"
string"

but not:
first   stringsecondstring

Suliman:

> I understand it.
>
> I expect what concatenation symbol will stay new line in new line and not append it's to current:
>
> 	writeln(
> 	"first string"
> 	"second" ~
> 	"string"
> 	);
>
> I expect:
> first string
> second"
> string"
>
> but not:
> first   stringsecondstring

If I compile and run this program:

void main() {
    import std.stdio;
    writeln(
    "first string"
    "second" ~
    "string"
    );
}


I see this output (and it's correct, as expected):

first stringsecondstring

Bye,
bearophile

On Thursday, 20 November 2014 at 10:41:24 UTC, bearophile wrote:
> uri:
>
>> It's by design
>
> And it's a nice handy design.
>
> Bye,
> bearophile

For Wysiwyg strings I agree that it's great but I prefer C/C++/Python like behaviour for double quoted strings. I guess it's what I'm used to :)




Cheers,
uri

On Thursday, 20 November 2014 at 11:08:24 UTC, Suliman wrote:
> 	writeln(
> 	"first string"
> 	"second" ~
> 	"string"
> 	);
>
> I expect:
> first string
> second"
> string"

There's no quoted newline there. You could do:

writeln(
"first string
second
string");

with the newlines enclosed in the quotes, then you'd get what you want. (There's no extra indenting in my example because the indent would show up too when inside quotes)

But if it isn't in the quotes, newlines are basically ignored by the compiler like any other whitespace in the code.

On 11/20/14, 9:05 AM, uri wrote:
> On Thursday, 20 November 2014 at 10:41:24 UTC, bearophile wrote:
>> uri:
>>
>>> It's by design
>>
>> And it's a nice handy design.
>>
>> Bye,
>> bearophile
>
> For Wysiwyg strings I agree that it's great but I prefer C/C++/Python
> like behaviour for double quoted strings. I guess it's what I'm used to :)
>
>
>
>
> Cheers,
> uri
>
>

In Crystal we chose the following: you can have two consecutive string literals but only if they are separated by a `\` at the end of the line.

So this is a syntax error:

foo("bar" "baz")

But this is ok:

foo("bar" \
    "baz")

Likewise, this is an error:

["foo", "bar" "baz", "qux"] # most probably we forgot to add a comma

But this is ok:

["foo", "bar" \
 "baz", "qux"]

This way you avoid silly typing mistakes while at the same time you allow splitting a string across several lines without having to concatenate them at runtime.

On Thu, 20 Nov 2014 14:23:23 -0300
Ary Borenszweig via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> This way you avoid silly typing mistakes while at the same time you allow splitting a string across several lines without having to concatenate them at runtime.
i bet that current D frontend is able to concatenate string literals in compile time.

On Friday, 21 November 2014 at 15:00:31 UTC, ketmar via Digitalmars-d-learn wrote:
> On Thu, 20 Nov 2014 14:23:23 -0300
> Ary Borenszweig via Digitalmars-d-learn
> <digitalmars-d-learn@puremagic.com> wrote:
>
>> This way you avoid silly typing mistakes while at the same time you allow splitting a string across several lines without having to concatenate them at runtime.
> i bet that current D frontend is able to concatenate string literals in
> compile time.

AFAIK yes. There was a change to guarantee that string literals concatenated by ~ are joined at compile time. The goal was to deprecated concatenation by juxtaposition, which hasn't happened yet, though.