On Friday, 7 February 2020 at 13:37:15 UTC, Adam D. Ruppe wrote:
> read my document here: https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f

Adam I was reading your document and I have a question in an example where you wrote:

> // look at this clean new code :D
> auto window = createWindow(i"Process debugger $pid");

> It compiles without error. In bliss, the happy user thinks: "d rox". Then... the program is run and the window width is extraordinary. But the documentation says it will be automatically sized by default. ... After some time, they notice the window title has changed to ...

So for what I understood, the currently "DIP 1027" when calling:

createWindow(i"Process debugger $pid")

Will generate a string "with" comma, like:

createWindow("Process debugger", $pid)

So changing the size of the window according the value in $pid.

Well if this is true, then this "DIP 1027" is not reasonable at all and really need some work.

Matheus.

On Friday, 7 February 2020 at 13:53:27 UTC, matheus wrote:
> createWindow(i"Process debugger $pid")
>
> Will generate a string "with" comma, like:
>
> createWindow("Process debugger", $pid)

Almost, Walter's proposal hardcodes %s in the compiler so it would actually generate:

createWindow("Process debugger %s", $pid)

> So changing the size of the window according the value in $pid.

but yes, indeed.

On Friday, 7 February 2020 at 13:56:54 UTC, Adam D. Ruppe wrote:
> createWindow("Process debugger %s", $pid)

oops no $ there of course.

BTW I actually think % or something is a better choice like $ for the interpolation. I'm not really going to fight it since I don't care that much, but for people who want to use it for D code snippets just remember that

a = a[1 .. $]

is really common in D code... and that $ will have to be escaped here. No big deal just wanna point it out while it is on my mind.

On Friday, 7 February 2020 at 13:59:23 UTC, Adam D. Ruppe wrote:
> On Friday, 7 February 2020 at 13:56:54 UTC, Adam D. Ruppe wrote:
>> createWindow("Process debugger %s", $pid)
>
> oops no $ there of course.
>
> BTW I actually think % or something is a better choice like $ for the interpolation. I'm not really going to fight it since I don't care that much, but for people who want to use it for D code snippets just remember that
>
[snip]

I recall Walter changing it to $ from something with % because that is what most other languages do.

On Friday, 7 February 2020 at 14:38:57 UTC, jmh530 wrote:
> I recall Walter changing it to $ from something with % because that is what most other languages do.

Right. But those other languages aren't putting D code in their strings, which use $ as a fairly common symbol in array indexes. A less common symbol in D would probably be #, which ruby uses for its interpolation.

It really isn't a big deal (I'm skeptical that interpolation will be of much value to mixins anyway), just something I want to make sure we're all aware of.

On Wednesday, 5 February 2020 at 05:26:30 UTC, Walter Bright wrote:
> The reason for formatted strings is for formatting that is other than the default, and to interface with common functions that use formatted strings.

So the proposed design makes it impossible for a library to verify arguments are correctly corresponding to format specifiers, not even at runtime. The programmer is expected to know the format conventions of the function.

Considering that, what is the purpose of putting the format specifier inside brackets {}?
Take for example this format string using range formatting specifiers from Phobos:

```
byte[] arr = [0x10, 0x1A, 0x1F];
writefln("arr = ${%(%X; %)}arr"); // entire format specifier in {}
writefln("arr = %(${%X}arr; %)"); // only element specifier in {}
```

The %( %) format specifiers are not the most beautiful to begin with, but the mandatory {} make it only worse. I would prefer to write:
```
writefln("The array is %(%s; %)$arr");
```

It's not like the {} add any delimiting / error checking of any kind, so I might as well put the format specifier in the string myself. This would also be required if the format string itself contained unbalanced {} in them, since no means of escaping { is provided.

But this still would not work with the current proposal, since a stray %s will be written into the string because of the absence of {}. Which, as mentioned before, is a direct contradiction with the design goal "the language does not now anything about format specifiers".

One idea is to just write nothing instead of %s, and removing the {}, which would be less typing and remove the hard-wired Phobos convention from the language.

Of course, with Steven/Adam's proposal, this can be made to work:
```
writefln("arr = ${X; }arr");
```

Here the {} can actually do the delimiting instead of %( and %), and possibly do error checking as well!

> Strings and expressions are stuck with the default format. If you're happy with the default formatting,
>
>     writefln("I want $i bananas");
>
> is not much of any improvement over:
>
>     writeln("I want ",i," bananas");

That second one is more prone to mistakes with whitespace, e.g.:

> text("a is", a, ", b is ", b, " and the sum is: ", a + b);

From: https://forum.dlang.org/post/jahvdekidbugougmyhgb@forum.dlang.org

Replying from review thread:

On Wednesday, 12 February 2020 at 11:49:11 UTC, Juraj Mojzis wrote:
> On Thursday, 30 January 2020 at 09:47:43 UTC, Mike Parker wrote:
>> This is the feedback thread for DIP 1027, "String Interpolation".
>
> If
> writefln(i"I ate $apples and ${%d}bananas totalling $(apples + bananas) fruit.");
> gets rewritten as:
> writefln("I ate %s and %d totalling %s fruit.", apples, bananas, apples + bananas);
>
> Than for function:
> void my_err_log(string err_msg, string file, int line, int char) {...}
>
> called as:
> my_err_log(i"Error loading image $image_path.", src_file, src_line, src_char);
>
> gets rewritten as:
> my_err_log("Error loading image %s message", image_path, src_file, src_line, src_char);
>
> Results in an error but users will expect this to work.
>
> Worst case scenario is function that match:
> void draw_text(string text, int optional_x = 0, int optional_y = 0) {...}
> callad as:
> draw_text(i"Today is $day.$month.");
>
>
> For example, Phobos exceptions are mostly defined as :
> this(string msg, string file = null, size_t line = 0)
> this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable next = null)
> etc.
>
> In my opinion, this is the fundamental flaw in the proposal.

Code that users expect to work resulting in an understandable error is the second-best outcome there is.

Since we don't have strong AI yet, given a situation that the compiler doesn't understand, this is pretty much the best result we can hope for. D has made a deliberate decision to eschew implicit conversions, so I don't think asking people to write

my_error_log(i"Error loading image $image_path".format, src_file, src_line, src_char);

instead is a big ask.

Re draw_text(), this is a valid problem and more ammunition for the 'i"" should return a templated struct' proposal, which would neatly eliminate this issue.

On Friday, 7 February 2020 at 22:48:03 UTC, Dennis wrote:

> Considering that, what is the purpose of putting the format specifier inside brackets {}?

Brackets are necessary to distinguish variables from other alpha-numeric characters.
Eg. In shell (bash) programming, you can specify variables as $VARNAME
or ${VARNAME}, the second form only necessary if the variable is adjacent
to any alphanumeric characters.

So, having said that, I would have thought that syntax like this would be better:

1. $variable
2. ${variable}
3. ${variable%d}, and eg. ${variable%02d}

so that form 1 can be used when the variable is bounded by whitespace or punctuation
but form 2 is needed to distinguish it from any adjacent alnum chars.

Eg. "/tmp/prog${random}whatever"

Form 3 would be for numeric type variables and allows optional formatting.