October 20, 2023
On Friday, 20 October 2023 at 08:03:55 UTC, Walter Bright wrote:
> On 10/19/2023 6:52 PM, Steven Schveighoffer wrote:
>> [...]
>
> I don't recall this issue even being discussed in the old review of it. It isn't listed in the review objections for DIP1027.
>
> [...]

What are your main objections to this

https://github.com/John-Colvin/YAIDIP

October 20, 2023
On Friday, 20 October 2023 at 13:03:45 UTC, Imperatorn wrote:
> On Friday, 20 October 2023 at 08:03:55 UTC, Walter Bright wrote:
>> On 10/19/2023 6:52 PM, Steven Schveighoffer wrote:
>>> [...]
>>
>> I don't recall this issue even being discussed in the old review of it. It isn't listed in the review objections for DIP1027.
>>
>> [...]
>
> What are your main objections to this
>
> https://github.com/John-Colvin/YAIDIP

It looks like a good DIP, and as a plus it has an implementation:
https://github.com/dlang/dmd/pull/15714

And the DIP is based on prior DIPs and co-written by Andrei.

I think it looks reasonable. Please take a second look if possible.
October 20, 2023

On Friday, 20 October 2023 at 07:14:45 UTC, Walter Bright wrote:

>

This code can be adapted to do whatever output schema one wants. Compare the tuple generated by DIP1027:

tuple("format %s %s sss", abc, 73)

and with YAIDIP:

tuple(.object.imported!"core.interpolation".InterpolationHeader!("", "format ", "", abc, "", 73, "", " sss", ""), "", "format ", "", abc, "", 73, "", " sss", "")

If this is supposed to be a favorable comparison of 1027, this has failed.

1027 requires runtime processing of a compile-time format string. It requires that you implement escapes for the %s spec and for literal %, or just know that your domain doesn't have a valid use for %s normally (though this always can be proven to be a mistake by users). It is not friendly to multiple interpolation strings sent to the same function (how does the function know this is a new header?)

YAIDIP or 1036, there is no discarding of the processing the compiler already did to parse the format string. Think about that -- with 1027 the compiler parsed the interpolation tuple, and built a puzzle string for you to have to figure out what it did during runtime.

Who cares what the generated tuple looks like? Nobody will see it. Do you care what other lowerings in the compiler look like? Because a lot of times they are god-awful monstrosities that nobody would write themselves. Is that something to object to?

All the proposed solutions, including 1027, can be worked with for most cases. It's just that the code to adapt 1027 to calls except for printf and writef is awful. It doesn't handle other situations at all.

And 1027 still has the problem of matching functions it shouldn't match. Do you recall Adam's example of exception construction?

throw new Exception(i"Invalid integer value in $file: $val");

-Steve

October 20, 2023

On Friday, 20 October 2023 at 13:45:40 UTC, Steven Schveighoffer wrote:

>

On Friday, 20 October 2023 at 07:14:45 UTC, Walter Bright wrote:

>

This code can be adapted to do whatever output schema one wants. Compare the tuple generated by DIP1027:

I'm just happy that I now can do this

String interpolation

Next is just to integrate into the rest of the tools.

October 20, 2023

On Friday, 20 October 2023 at 13:45:40 UTC, Steven Schveighoffer wrote:

>

On Friday, 20 October 2023 at 07:14:45 UTC, Walter Bright wrote:

>

[...]

If this is supposed to be a favorable comparison of 1027, this has failed.

1027 requires runtime processing of a compile-time format string. It requires that you implement escapes for the %s spec and for literal %, or just know that your domain doesn't have a valid use for %s normally (though this always can be proven to be a mistake by users). It is not friendly to multiple interpolation strings sent to the same function (how does the function know this is a new header?)

YAIDIP or 1036, there is no discarding of the processing the compiler already did to parse the format string. Think about that -- with 1027 the compiler parsed the interpolation tuple, and built a puzzle string for you to have to figure out what it did during runtime.

Who cares what the generated tuple looks like? Nobody will see it. Do you care what other lowerings in the compiler look like? Because a lot of times they are god-awful monstrosities that nobody would write themselves. Is that something to object to?

All the proposed solutions, including 1027, can be worked with for most cases. It's just that the code to adapt 1027 to calls except for printf and writef is awful. It doesn't handle other situations at all.

And 1027 still has the problem of matching functions it shouldn't match. Do you recall Adam's example of exception construction?

throw new Exception(i"Invalid integer value in $file: $val");

-Steve

thank you.
i agree, YAIDIP is the best solution so far, but i think we should take a step back and think about the real porblem: why can't we do it with existing language features, and what would be required to simply make foo(i!"cool ${var} rox"); work instead. because adding that feature might benefit a lot more use cases.

October 20, 2023

On Friday, 20 October 2023 at 14:13:44 UTC, Imperatorn wrote:

>

On Friday, 20 October 2023 at 13:45:40 UTC, Steven Schveighoffer wrote:

>

On Friday, 20 October 2023 at 07:14:45 UTC, Walter Bright wrote:

>

This code can be adapted to do whatever output schema one wants. Compare the tuple generated by DIP1027:

I'm just happy that I now can do this

String interpolation

Next is just to integrate into the rest of the tools.

Just look at this. You know you want it 😅

October 20, 2023

On Friday, 20 October 2023 at 15:29:29 UTC, Commander Zot wrote:

>

why can't we do it with existing language features, and what would be required to simply make foo(i!"cool ${var} rox"); work instead. because adding that feature might benefit a lot more use cases.

Because templates are lexically scoped, the body of the i template would not be able to access var when expanding the string "cool ${var} rox".

The only way in D for a template to access the scope where it's used instead of the scope where it's defined is to use a mixin (either string or template). So the best we can do with current language features is foo(mixin(i!"cool ${var} rox")). (And indeed, there are libraries on code.dlang.org that do this.)

So, I guess the minimal language feature that would allow your example to work would be the ability to define a template whose result is implicitly mixed-in to the instantiating scope, without having to use the mixin keyword.

However, I doubt such a feature would be accepted. The whole point of requiring the mixin keyword is to signal to anyone reading the code that this is a place where D's normal scoping rules might be violated. Allowing that to happen implicitly would defeat the purpose of having a mixin keyword in the first place.

October 20, 2023

On Friday, 20 October 2023 at 15:47:17 UTC, Imperatorn wrote:

>

On Friday, 20 October 2023 at 14:13:44 UTC, Imperatorn wrote:

>

On Friday, 20 October 2023 at 13:45:40 UTC, Steven Schveighoffer wrote:

>

On Friday, 20 October 2023 at 07:14:45 UTC, Walter Bright wrote:

>

This code can be adapted to do whatever output schema one wants. Compare the tuple generated by DIP1027:

I'm just happy that I now can do this

String interpolation

Next is just to integrate into the rest of the tools.

Just look at this. You know you want it 😅

LGTM merge... (if I could :p)

October 20, 2023

On Friday, 20 October 2023 at 13:45:40 UTC, Steven Schveighoffer wrote:

>

All the proposed solutions, including 1027, can be worked with for most cases. It's just that the code to adapt 1027 to calls except for printf and writef is awful. It doesn't handle other situations at all.

I misspoke, 1027 doesn't actually handle printf very well, you still have to include the format specifiers for anything other than a char *. Only writef makes sense.

Whereas, with DIP1036, I already wrote an overload that works with printf without needing any specifiers, and is betterC compatible, it should lower to one call to core.stdc.stdio.printf.

import core.stdc.stdio;
import std.traits;

struct interp(string s)
{
    static string toString() { return s; }
}

alias printf = core.stdc.stdio.printf;

auto printf(Args...)(Args args) if (isInstanceOf!(interp, Args[0]))
{
    static immutable formatStr = () {
        string result;
        foreach(T; Args)
            static if(isInstanceOf!(interp, T))
                result ~= T.toString();
            else static if(is(T == int))
                result ~= "%d";
            else static if(is(T : const(char)[]))
                result ~= "%.*s";
            else static if(is(T == float) || is(T == double))
                result ~= "%f";
            // .. and so on
        return result ~ "\0";
    }();

    mixin(() {
        string result = "return core.stdc.stdio.printf(formatStr.ptr";
        foreach(i, T; Args)
            static if(!isInstanceOf!(interp, T)){
                static if(is(T : const(char)[]))
                    result ~= ", cast(int)args[" ~ i.stringof ~ "].length, args[" ~ i.stringof ~ "].ptr";
                else
                    result ~= ", args[" ~ i.stringof ~ "]";
            }
        return result ~ ");";
    }());
}

extern(C) void main()
{
    string name = "Walter";
    int age = 42;
    // equivalent of printf(i"Hello, ${name}, you are ${age} years old.\n");
    printf(interp!"Hello, "(), name, interp!", you are "(), age, interp!" years old.\n"());
    printf("And normal printf works too, %s\n", name.ptr);
}

-Steve

October 20, 2023

On Friday, 20 October 2023 at 16:15:52 UTC, Daniel N wrote:

>

On Friday, 20 October 2023 at 15:47:17 UTC, Imperatorn wrote:

>

On Friday, 20 October 2023 at 14:13:44 UTC, Imperatorn wrote:

>

On Friday, 20 October 2023 at 13:45:40 UTC, Steven Schveighoffer wrote:

>

On Friday, 20 October 2023 at 07:14:45 UTC, Walter Bright wrote:

>

LGTM merge... (if I could :p)

Hehe, I posted some instructions here if you want to try it out:
https://forum.dlang.org/post/rkevblyfgvmvmsuhtqmr@forum.dlang.org