This is the discussion thread for the second round of Community Review of DIP 1036, "String Interpolation Tuple Literals":

https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md

The review period will end at 11:59 PM ET on February 10, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Wednesday, 27 January 2021 at 10:33:08 UTC, Mike Parker wrote:
>>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post.

The Feedback Thread is here:
https://forum.dlang.org/post/bvrejaayzpgbykacxrxe@forum.dlang.org

On Wednesday, 27 January 2021 at 10:33:08 UTC, Mike Parker wrote:
> This is the discussion thread for the second round of Community Review of DIP 1036, "String Interpolation Tuple Literals":

IMO this version of the DIP has the same fundamental problem as the previous one: it's Good Work, but not Great Work. [1]

I can imagine a version of DIP 1036 that *would* be Great Work--one that dropped the overweight .idup feature and shifted its focus to metaprogramming applications--but that's not the version the authors want to write, so I expect I'll never get to see it.

[1] https://forum.dlang.org/post/q7u6g1$94p$1@digitalmars.com

On Wednesday, 27 January 2021 at 14:36:10 UTC, Paul Backus wrote:
> shifted its focus to metaprogramming applications

What metaprogramming applications are you missing?

On Wednesday, 27 January 2021 at 14:52:39 UTC, Adam D. Ruppe wrote:
> On Wednesday, 27 January 2021 at 14:36:10 UTC, Paul Backus wrote:
>> shifted its focus to metaprogramming applications
>
> What metaprogramming applications are you missing?

The problem isn't that anything's missing, it's that there's too much there in the first place. DIP 1036 is essentially two separate string interpolation proposals (the .idup version and the tuple version) awkwardly stitched together, and the presence of the stitching makes both of them worse than either would be on its own.

On 1/27/21 10:06 AM, Paul Backus wrote:
> On Wednesday, 27 January 2021 at 14:52:39 UTC, Adam D. Ruppe wrote:
>> On Wednesday, 27 January 2021 at 14:36:10 UTC, Paul Backus wrote:
>>> shifted its focus to metaprogramming applications
>>
>> What metaprogramming applications are you missing?
> 
> The problem isn't that anything's missing, it's that there's too much there in the first place. DIP 1036 is essentially two separate string interpolation proposals (the .idup version and the tuple version) awkwardly stitched together, and the presence of the stitching makes both of them worse than either would be on its own.

I have the exact opposite experience. The previous DIP elicited multiple questions on why it was so complex to just get a string out of such a literal. Why do I have to add `.text` or `.idup` they would say. This includes Andrei, who said he would never use the tuple form, just the string form, and if it didn't "just work" it was a failed feature (this is my recollection from a phone call, so it's possible I misunderstood).

Without the tuple portion, it's just another run-of-the-mill string interpolation feature, which is OK, but just leaves all of D's power on the table.

Without the auto-conversion to string, it's a never-been-seen-before metaprogramming feature that people just looking to get a string from their data will have a hard time using.

With both together, it's a cohesive (not awkward, fully disagree on that) setup that does the intuitive thing if you don't know how it actually works under the hood, but provide the exact power you need for hooking string interpolation when you know about it, and ONLY if you want it. I can't imagine how you could make this more metaprogramming friendly than it is. I find it to be Great Work as defined by your link. In fact, part of the inspiration of adding the idup rewrite was from the talk you referred to (in the first review) from Scott Meyers where he says that the most obvious thing should be what it does. The most obvious thing you get from a string literal is a string.

You and others may disagree, but if this doesn't make it through, I don't know what would.

-Steve

It appears to have abandoned being usable with printf?

On Thursday, 28 January 2021 at 06:12:14 UTC, Walter Bright wrote:
> It appears to have abandoned being usable with printf?

Well a simple way is `printf("%s", text(i"hello ${name1}, ${name2} and {name3}!"))`. Works, but not in a no-gc way unless you redefine `Interp!()` yourself.

Even without touching `Interp!()` you could do a function that prints an interpolated string with `printf` without using the GC, as long as the format specifier is known at compile time. The function introspects the received `Interp!string` struct types and makes the correct format specifier from them at compile-time and feeds it along with rest of the arguments to `printf`. This is more complicated of course.

On 1/27/2021 11:16 PM, Dukc wrote:
> On Thursday, 28 January 2021 at 06:12:14 UTC, Walter Bright wrote:
>> It appears to have abandoned being usable with printf?
> 
> Well a simple way is `printf("%s", text(i"hello ${name1}, ${name2} and {name3}!"))`. Works, but not in a no-gc way unless you redefine `Interp!()` yourself.

Nobody is going to prefer calling printf that way.

Redefining a custom Interp template is a no-go, too, as then the code is incompatible with common usage code.


> Even without touching `Interp!()` you could do a function that prints an interpolated string with `printf` without using the GC, as long as the format specifier is known at compile time. The function introspects the received `Interp!string` struct types and makes the correct format specifier from them at compile-time and feeds it along with rest of the arguments to `printf`. This is more complicated of course.

Sounds complicated enough to be a non-starter.

On Thursday, 28 January 2021 at 07:44:05 UTC, Walter Bright wrote:
> On 1/27/2021 11:16 PM, Dukc wrote:
>> On Thursday, 28 January 2021 at 06:12:14 UTC, Walter Bright wrote:
>>> It appears to have abandoned being usable with printf?
>> 
>> Well a simple way is `printf("%s", text(i"hello ${name1}, ${name2} and {name3}!"))`. Works, but not in a no-gc way unless you redefine `Interp!()` yourself.
>
> Nobody is going to prefer calling printf that way.
>

Yeah, easier to just use `std.stdio.write`.

> Redefining a custom Interp template is a no-go, too, as then the code is incompatible with common usage code.
>

I wouldn't like that either.

>
>> Even without touching `Interp!()` you could do a function that prints an interpolated string with `printf` without using the GC, as long as the format specifier is known at compile time. The function introspects the received `Interp!string` struct types and makes the correct format specifier from them at compile-time and feeds it along with rest of the arguments to `printf`. This is more complicated of course.
>
> Sounds complicated enough to be a non-starter.

...but on that I disagree. It can be a library function. I am not sure whether it should be in Phobos, in some DUB package, or just copy-pasted around, but in any case one would not need to face the complexity oneself to use it.