On Wednesday, 11 December 2019 at 12:50:34 UTC, Ernesto Castellotti wrote:
> On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
>> [...]
>
> From the dip it seems that it is only valid for writefln & co
> So a code like:
>    auto myText = i"I ate% apples"
> would not be valid.

It is allowed everywhere where a tuple expression is allowed

auto myText = "I ate%s", apples

doesn't make sense

>
> Correct me if I'm wrong but from my point of view this "String interpolation" is completely useless.
> I wish D had a string interpolation like Kotlin

On Wednesday, 11 December 2019 at 15:41:56 UTC, Patrick Schluter wrote:
> On Wednesday, 11 December 2019 at 10:57:13 UTC, Alexandru Ermicioi wrote:
>> On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
>>> [...]
>>
>> Why not just split interpolated string into just a tuple of args & strings. For example:
>> Given: (i"I ate %apples and %bananas totalling %(apples + bananas) fruit.")
>> Is lowered to a tuple: ("I ate ", apples, " and ", bananas," totalling ", apples + bananas," fruit.")
>>
>> It seems current version unnecessarily ties to printf formatting syntax, and makes harder for them to be used in custom user code.
>>
>> Also user still needs call a function to get assembled string which differs from what other languages are doing with interpolated strings.
>>
>
> This wouldn't work for C formats like printf. The proposition has the nice property of being usable for DasBetterC and interfacing with C libraries that use format specifiers (libxml2 anyone?).

Indeed it doesn't, yet it falls nicely with std.conv.text, and variadic args versions of writeln, has less development overhead (no need to parse string for printf placeholders) when writing functions accepting resulting tuple from interpolation string, and could be made compatible with betterC mode by having a util func that transforms tuple to printf compliant version.

Best regards,
Alexandru.

On Wednesday, 11 December 2019 at 15:55:35 UTC, Patrick Schluter wrote:
> On Wednesday, 11 December 2019 at 12:50:34 UTC, Ernesto Castellotti wrote:
>> On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
>>> [...]
>>
>> From the dip it seems that it is only valid for writefln & co
>> So a code like:
>>    auto myText = i"I ate% apples"
>> would not be valid.
>
> It is allowed everywhere where a tuple expression is allowed
>
> auto myText = "I ate%s", apples
>
> doesn't make sense

It works already (un?)fortunately:

    auto test = AliasSeq!("The product of %s and %s is %s", 2, 5, 10);
    writeln(test);  //Prints "The product of %s and %s is %s2510"
    writefln(test); //Print   "The product of 2 and 5 is 10"

This DIP is just taking that 1 extra small step to allow i"" strings to be lowered to tuple literals.

On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1027, "String Interpolation":
>
> https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md
> [...]

This is amazing and I would use it straight away.

To preempt any suggestion to just use format with %n$s positional specifiers instead, I present to you non-trivial cases of Bash colour highlighting.

enum logtint = "\033[1;32m";
enum warningtint = "\033[1;31m";
enum resettint = "\033[0m";

writefln("%3$sException: %1$s%2$s%3$s (at %1$s%4$s%3$s:%1$s%5$d%3$s)%6$s",
    logtint, e.msg, warningtint, e.file, e.line, resettint);

I'm not really sure if the balance of added complexity vs. payoff is in favor of payoff.
They only time I felt the need for such a feature was when I had very long DelimitedStrings.
And those long strings where a constant source bugs, so I split them up and the field need for interpolated strings want away with the bugs.

Not being able to use * will stop me using this feature in many places.


The rationale about "missing arguments, wrong format specifier,... " Is a mute point IMO. format!"%d"(13.37) does the same thing already without any language change.
I thought the idea was not to introduce language changes if a library solution can do most of it already.
I find that the readability argument is highly subjective.
The first part of the rationale is, IHO,
already pointing to the solution. Short strings are easy to manage.
So let's promote short strings in
combination with format!"%s" and
output ranges.

How will this feature work at CT.
Format doesn't even work completely at CT.

I know this goes a bit off topic,
but IMO this is a feature that is wanted,
because other languages have it.
And we want to say we have it too.
I think it's a lot nicer to say, we don't need this, because our templates
can already do that.

TL/DR: not a fan

On Wednesday, 11 December 2019 at 18:58:46 UTC, Robert Schadek wrote:
> I'm not really sure if the balance of added complexity vs. payoff is in favor of payoff.
> They only time I felt the need for such a feature was when I had very long DelimitedStrings.
> And those long strings where a constant source bugs, so I split them up and the field need for interpolated strings want away with the bugs.
>
> Not being able to use * will stop me using this feature in many places.
>
>
> The rationale about "missing arguments, wrong format specifier,... " Is a mute point IMO. format!"%d"(13.37) does the same thing already without any language change.
> I thought the idea was not to introduce language changes if a library solution can do most of it already.
> I find that the readability argument is highly subjective.
> The first part of the rationale is, IHO,
> already pointing to the solution. Short strings are easy to manage.
> So let's promote short strings in
> combination with format!"%s" and
> output ranges.
>
> How will this feature work at CT.
> Format doesn't even work completely at CT.
>
> I know this goes a bit off topic,
> but IMO this is a feature that is wanted,
> because other languages have it.
> And we want to say we have it too.
> I think it's a lot nicer to say, we don't need this, because our templates
> can already do that.
>
> TL/DR: not a fan

It can *almost* already be done with templates:
https://github.com/Abscissa/scriptlike#string-interpolation

The main sticking point is that you have to write mixin(interp!"....") so the symbols will be looked up in the proper scope. Unfortunately, that also means that the above syntax is the best a library solution can do, currently.

On Wed, Dec 11, 2019 at 09:52:21AM +0000, Mike Parker via Digitalmars-d wrote:
> This is the feedback thread for the first round of Community Review for DIP 1027, "String Interpolation":
> 
> https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md
[...]

1) The way this DIP is worded belies its true power, which I suspect some people are unaware of.  Part of this is because the writefln/printf example chosen for the Description section makes it appear as though this DIP is only about writefln or printf formatting.

It would be nice(r) if the DIP included a section describing use cases outside of writefln.  For example: readable yet type-safe database query formatting: by writing a format string parser that turns '%x' into '?' and generates SQL bind commands for the corresponding arguments:

	string table = "mytable";
	string key = "key-that!needs'escap1ng";
	double value = 3.14159;
	int index = 12345;
	DateTime lastTime = getCurDate();

	database.exec(i"UPDATE %table SET key=%key, value=%{f}value WHERE index < %{d}index AND timestamp > %{D}lastTime");

(Note that '%D' is not a writefln-supported format, presumably it's
something database.exec() understands.)


2) The previous example does bring up another issue: is there a nice way to handle long interpolated strings, i.e., wrap long interpolated strings to multiple lines?  I.e., does the following work?

	database.exec(i"UPDATE %table SET key=%key, value=%{f}value "~
			"WHERE index < %{d}index AND "~
			"timestamp > %{D}lastTime");

If not, is there an alternative?  One of the key arguments of the DIP is that traditional format strings become unwieldy when the length increases and the number of arguments increases.  But how does the proposed interpolated string syntax mitigate the very same problems in its own syntax?


3) Someone has already pointed out the problem of interpreting %% as %, because:

	double grade = 89.5;
	writefln(i"Your grade is %{.2f}grade%%.");

gets turned into:

	double grade = 89.5;
	writefln("Your grade is %.2f%.", grade);

Note the dangling % at the end, which will writefln to throw an error. Under the current syntax, you'd have to write "%%%%" to get a single '%' in the writefln output, which seems excessive.

Counterproposal: %% should be copied literally as %% in the output.


T

-- 
PNP = Plug 'N' Pray

On Wednesday, 11 December 2019 at 18:58:46 UTC, Robert Schadek wrote:
> I'm not really sure if the balance of added complexity vs. payoff is in favor of payoff.

Disagree. This proposition strikes exactly the right balance imho. The other syntaxes proposes that lean more on Java/C# I would agree with you. This proposition though is just a simple composition of the existing C heritage and the availaible D feature (tuple).

> They only time I felt the need for such a feature was when I had very long DelimitedStrings.
> And those long strings where a constant source bugs, so I split them up and the field need for interpolated strings want away with the bugs.

So you complexified your code because of a restriction of the language.

>
> Not being able to use * will stop me using this feature in many places.
>
>
> The rationale about "missing arguments, wrong format specifier,... " Is a mute point IMO. format!"%d"(13.37) does

MOOT not mute

> the same thing already without any language change.
> I thought the idea was not to introduce language changes if a library solution can do most of it already.
> I find that the readability argument is highly subjective.

It is but it is also true that from more than 4 parameters in a format string it gets more and more noisy.

> The first part of the rationale is, IHO,
> already pointing to the solution. Short strings are easy to manage.
> So let's promote short strings in
> combination with format!"%s" and
> output ranges.
>
> How will this feature work at CT.
> Format doesn't even work completely at CT.

It's a problem with format and is perpendicular to this DIP, i.e. if this DIP is adopted or not, it will not change anything to the issues of format.

>
> I know this goes a bit off topic,
> but IMO this is a feature that is wanted,
> because other languages have it.
> And we want to say we have it too.

May be sometimes it is good to look why certain features are spreading like wildfire. C format specifiers were a regression compared to what was available at that time (in Pascal or even Cobol), but as C had so much other things to it, people tended to accept the strange and ugly printf formatting, but it's clear that i was universally loathed. That's why C++ tried this worse shift syntax and other languages tried other solutions.
It is not because we in the end managed to get used to the outdated and dangerous printf format that it is good in the first place.
This DIP is simple enough that it is a good candidate imho to be tried.

> I think it's a lot nicer to say, we don't need this, because our templates
> can already do that.
>

On Wednesday, 11 December 2019 at 19:34:01 UTC, Patrick Schluter wrote:
> Cobol), but as C had so much other things to it, people tended to accept the strange and ugly printf formatting, but it's clear that i was universally loathed. That's why C++ tried this worse shift syntax and other languages tried other solutions.
> It is not because we in the end managed to get used to the outdated and dangerous printf format that it is good in the first place.
> This DIP is simple enough that it is a good candidate imho to be tried.

If something is bad… (…and I agree, printf is not good.) Why would you embrace it by making it part of the language?

Currently it only part of a library and can be phased out. Make it part of the language and you'll be stuck with it. Creating a better solution and create a wrapper for printf and other C-APIs would be the better approach.

Otherwise you'll end up with another interpolated string version... down the road. How many string-literals can a language handle?

On Wednesday, 11 December 2019 at 19:15:18 UTC, Meta wrote:
> The main sticking point is that you have to write mixin(interp!"....") so the symbols will be looked up in the proper scope. Unfortunately, that also means that the above syntax is the best a library solution can do, currently.

Maybe "mixin" could be a return type requiring CTFE and re-evaluated in the calling context?  A bit dangerous perhaps.