On Monday, 23 October 2023 at 19:25:35 UTC, Walter Bright wrote:
> Adam strongly criticized my review of YAIDIP because that was not how his implementation worked.

Not true. I criticized your review of YAIDIP because you were wrong about what YAIDIP said.

I then implemented YAIDIP, exactly as written, to clear up further misconceptions:

https://github.com/dlang/dmd/pull/15714

This PR is *still* YAIDIP implemented, exactly as written.

Though YAIDIP has its own flaws, including ones fixed in DIP1036, so I then adjusted the patch to fix those in a *separate* PR (15715), which is a better proposal.

I'm no longer interested in YAIDIP, I consider it dead. Its flaws are addressed in PR 15715 (a very minor modification to the previous patch). But the document and PR are still there to be examined anyway.

> I don't know how his implementation works, because there is no specification for it.

The newest one's implementation is crystal clear, fully operational in a trivial patch to the compiler, along with several usage examples.

You're just making excuses now.

On Monday, 23 October 2023 at 20:37:00 UTC, Adam D Ruppe wrote:
> On Monday, 23 October 2023 at 19:25:35 UTC, Walter Bright wrote:
>> [...]
>
> Not true. I criticized your review of YAIDIP because you were wrong about what YAIDIP said.
>
> [...]


For others reading, here's the new one, Dip1036e :

https://github.com/dlang/dmd/pull/15715

On Sunday, 22 October 2023 at 19:51:17 UTC, Imperatorn wrote:
> On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:
>> On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:
>>> Several people asked for an implementation to try out, so here it is:
>>>
>>> https://github.com/dlang/dmd/pull/15722
>>
>> s/i/format!
>
> You forgot /g 😎

I forgot to mention that baking a feature that works just fine as a library in the language is a terrible idea.

On Tuesday, 24 October 2023 at 11:32:19 UTC, deadalnix wrote:
> On Sunday, 22 October 2023 at 19:51:17 UTC, Imperatorn wrote:
>> On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:
>>> On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:
>>>> Several people asked for an implementation to try out, so here it is:
>>>>
>>>> https://github.com/dlang/dmd/pull/15722
>>>
>>> s/i/format!
>>
>> You forgot /g 😎
>
> I forgot to mention that baking a feature that works just fine as a library in the language is a terrible idea.

Does that mean any string interpolation solution should be solved as a library or just some of them?

On Tuesday, 24 October 2023 at 11:32:19 UTC, deadalnix wrote:
> On Sunday, 22 October 2023 at 19:51:17 UTC, Imperatorn wrote:
>> On Sunday, 22 October 2023 at 19:35:46 UTC, deadalnix wrote:
>>> On Sunday, 22 October 2023 at 08:56:06 UTC, Walter Bright wrote:
>>>> Several people asked for an implementation to try out, so here it is:
>>>>
>>>> https://github.com/dlang/dmd/pull/15722
>>>
>>> s/i/format!
>>
>> You forgot /g 😎
>
> I forgot to mention that baking a feature that works just fine as a library in the language is a terrible idea.

Exactly. But the language currently lacks the tools to do it in a nice way. we'd need something like this:

```d
template FOO(T) {
    alias FOO = T;
}
pragma(msg, FOO!int); // FOO decays into int

template BAR(alias T) {
    enum BAR = T;
}
pragma(msg, BAR!42); // BAR decays into 42

// proposed new feature: automatic string mixins
template BAZ(string T) {
    mixin BAZ = T;
}
pragma(sg, BAZ!"42, 42"); // BAZ should decays into pragma(msg, mixin("42, 42"));
// note: mixin("42, 42") curently doesn't work either. but it sould be made to work so it becomes:
// pragma(msg, 42, 42);

```

would this be possible to implement in the compiler?

On 10/23/2023 1:37 PM, Adam D Ruppe wrote:
> Not true. I criticized your review of YAIDIP because you were wrong about what YAIDIP said.

Since you abandoned it, there's no point in rebuttal.


>> I don't know how his implementation works, because there is no specification for it.
> The newest one's implementation is crystal clear, fully operational in a trivial patch to the compiler, along with several usage examples.

Please write a specification for it. There's not even a grammar for it, and the pull request has no test cases.

When there is one, I will review it.

On 10/23/2023 10:01 PM, Imperatorn wrote:
> For others reading, here's the new one, Dip1036e :
> 
> https://github.com/dlang/dmd/pull/15715

It's not a specification, it's a code PR.

On Tuesday, 24 October 2023 at 18:13:58 UTC, Walter Bright wrote:
> Please write a specification for it. There's not even a grammar for it, and the pull request has no test cases.

Being able to see what the tuple is is much more educational than a lot of handwavy documentation. It removes all the mystery. A lot of people seem to assume that tuple generation is far more complicated than it is.

On 10/24/2023 4:32 AM, deadalnix wrote:
> I forgot to mention that baking a feature that works just fine as a library in the language is a terrible idea.

True, but can it work as a library feature? Consider:

```
void test {
    int x = 78;
    func("x = $x");
}
```

In order for this to work, `x` has to undergo semantic analysis in the context of `test`. But it will get evaluated in the context of `func`, which would be incorrect.

The way to evaluate it in the context of `test` is to have `func` return a string and then apply a mixin. (There may be another way, but I can't think of one.)

So, it would have to be written as:

```
    mixin(func("x = $x");
```

As a general rule, things that are used a lot can benefit from syntactic sugar, which is what DIP1027 provides.

On Tuesday, 24 October 2023 at 18:15:25 UTC, Walter Bright wrote:
> On 10/23/2023 10:01 PM, Imperatorn wrote:
>> For others reading, here's the new one, Dip1036e :
>> 
>> https://github.com/dlang/dmd/pull/15715
>
> It's not a specification, it's a code PR.

Just posting the link for those who don't know what's being discussed