On Wednesday, 27 January 2021 at 16:54:30 UTC, Steven Schveighoffer wrote:
> ...

+1

I'm quite biased, but this approach is more similar to how C# handles things, and not having to jump through hoops just to make a string is a lot more obvious and user-friendly.

I fear the ultimate fate of this DIP is rejection though, but in my not so honest opinion this is a better iteration of the previous attempt.

Honestly, pretty much all of my major points have already been argued by others during the last discussion of this DIP, so I don't really have anything new to add other than: What's the main priority between making it easy to use and obvious, or making it less easy to use for... reasons?

Why are we scared of adding usage of the GC for small quality of life things (implicit string conversion)? Even if the DIP specifies a way to avoid GC usage?

It's kind of like we're silently admitting that the GC is a hindrance, and so is to be avoided for any new features, which in turn (to my fragile c# eyes at least) is being compromised for making the obvious, common use cases (implicit string conversion) harder to use.

Which is why I believe this DIP's surface value is much better than the attempt before. I'm not able to comment on all the nitty gritty technical details though, which I understand may have issues.

Again though, I'm largely biased towards the most common use case being the simplest and most obvious use case. Which for people comparing this feature to languages like C# and JS, it'd be implicit string conversion that's out of your way.

And disclaimer on these thoughts: I personally have no interest in the tuple form of an interp string in spite of recognising its value and potential, so my bias is simply towards string conversion.

Finally, and I'm sorry if I missed this being described in the DIP, but consider this case (and similar):

```
void f(T)(T array)
if(isArray!T)
{
    //...
}

f(i"...");
```

What would happen here? My best guess is that it won't compile unless written as `f(i"...".idup)` which then introduces an odd discrepancy where there's certain usages that still require explicitly calling .idup, e.g. `i"...".idup.splitter`

On Thursday, 28 January 2021 at 07:44:05 UTC, Walter Bright wrote:
> Nobody is going to prefer calling printf that way.

Forgive me if I'm missing the point, but why should a D feature compromise itself for a small subset of C functions?

Kind of ironically the argument of "nobody is going to prefer calling printf that way" is similar to the argument of the previous printf-compatible proposal having to call an external function just to get a string.

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

Ranges don’t work with C functions, but that’s hardly an argument against ranges.

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":
>
> 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.

I am going to respond a comment in the feed back thread that bugs me.


>> requires the GC

>D needs to move away from such constructs.

No, it doesn't. I am starting to believe that the gc phobia that has been spread by the c++/c people has been a mistake, if d is starting to turn down productivity features because of it.

-Alex

On Thu, Jan 28, 2021 at 02:03:42PM +0000, 12345swordy via Digitalmars-d wrote: [...]
> > > requires the GC
> 
> > D needs to move away from such constructs.
> 
> No, it doesn't. I am starting to believe that the gc phobia that has been spread by the c++/c people has been a mistake, if d is starting to turn down productivity features because of it.
[...]

+1.

Though at the rate this ill-fated DIP has been going, I fear it may already be DOA. :-/


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.

On 1/28/21 1:12 AM, Walter Bright wrote:
> It appears to have abandoned being usable with printf?

Yes and no.

Yes, we do not think that using printf with interpolated strings *without modification* is an important goal. printf works fine as it is. This is D, not C. writeln IS usable without modifications.

And no, it is not abandoned, because it's perfectly possible because of the awesome power of metaprogramming allowed in this DIP:

https://run.dlang.io/is/X5HcXS

-Steve

On Thursday, 28 January 2021 at 14:03:42 UTC, 12345swordy wrote:

>>> requires the GC
>
>>D needs to move away from such constructs.
>
> No, it doesn't. I am starting to believe that the gc phobia that has been spread by the c++/c people has been a mistake, if d is starting to turn down productivity features because of it.

For those of us that want to do productive things with our time rather than fiddle around in the weeds of memory management, this is not a good sign. If I wanted to use Rust, I'd already be using it.

On 1/28/2021 12:50 AM, SealabJaster wrote:
> On Thursday, 28 January 2021 at 07:44:05 UTC, Walter Bright wrote:
>> Nobody is going to prefer calling printf that way.
> 
> Forgive me if I'm missing the point, but why should a D feature compromise itself for a small subset of C functions?

While the printf family is indeed a small subset of C functions, it is probably the most called one.

On Thursday, 28 January 2021 at 20:02:40 UTC, Walter Bright wrote:
> On 1/28/2021 12:50 AM, SealabJaster wrote:
>> On Thursday, 28 January 2021 at 07:44:05 UTC, Walter Bright wrote:
>>> Nobody is going to prefer calling printf that way.
>> 
>> Forgive me if I'm missing the point, but why should a D feature compromise itself for a small subset of C functions?
>
> While the printf family is indeed a small subset of C functions, it is probably the most called one.

That being said. Would it be easier to convince you to accept this if there is a prototype version of this?

- Alex

auto convoluted = i"${ir"`${"{"}`"}"; // nested string interpolations work.
assert(convoluted == "`{`");

Whoa, this looks impossible to lex.