String Interpolation Compare - DIP1027 and YAIDIP

[Steven Schveighoffer]

On Saturday, 21 October 2023 at 06:44:22 UTC, Walter Bright wrote:
> On 10/20/2023 9:42 PM, Steven Schveighoffer wrote:
>> Yes and no. It's very clearly geared towards writef (or else 
>> we would have some other default other than %s), even though 
>> it doesn't require hooking with writef. But in effect, writef 
>> and format (and other functions like it, such as loggers) are 
>> the only functions it works with "out of the box".
>
> That's no surprise, since Phobos has adopted that style for 
> more than just writef, such as std.format.format(). There's no 
> reason to invent a different one for loggers.
>
> https://dlang.org/phobos/std_format.html#format
>
> Besides, I had modified DIP1027 to enable any format string 
> between { } specifically to accommodate your database use case.

This is woefully inadequate. It requires users to participate in 
the details of the SQL format that are irrelevant to the function 
call, and it also allows people to do the wrong thing quite 
easily, with no compiler help. Statically typed languages are 
better than this, and especially D is. We don't want to make 
users have to know how the "sausage is made".

This is why I consider it a failure.

consider the even worse case of postgres -- all parameters 
require a positional index, so:

```
INSERT INTO tbl (name, age) VALUES ($1, $2)
```

Now, the user not only has to change the %s to $N, but they have 
to maintain the ordering of the indexes manually. These are the 
kinds of things that people "get used to" because they have no 
other options. Much better to let the function itself handle the 
proper placeholders that correspond to the implementation details 
of the usage.

You might say, "hey, that's just the way it is, you are using 
postgres". But what about a DB abstraction library? It might want 
to change the placeholders based on the underlying backend.

>> There are many other functions that use the same style of 
>> "blueprint + data" calls which will utterly fail, and can't be 
>> made to work with DIP1027.
>
> Example, please. I already showed how to do Adam's example of 
> things that wouldn't work with DIP1027.

The point I was making was that there are no other functions 
except writef and format that work, or can be made to work, 
directly with this mechanism (of course, without sausage-making 
by the user). Even printf requires the user to become involved.

Of course, it is possible to write a completely new function with 
a new name that will handle (poorly) the puzzle that the compiler 
constructed in its quirky writef-like way (oh, and make sure you 
don't change those placeholders, because we can't detect that!)

>> BTW, I count a failure as having to specify the correct 
>> substitution as the user. That is the domain of the function 
>> or the type system.
>
> I don't know what that means.

The {} thing you mentioned above. It does not suffice as 
discussed above. The user shouldn't have to be involved with 
figuring out placeholders when we have a perfectly capable 
compiler to do it for us.

>
> > Nobody, and I really truly mean, NOBODY, is clamoring for
> better ways to call printf (specifically printf).
>
> Which is too bad. printf has many advantages:

I was saying printf is fine the way it is, nobody needs new ways 
to call printf.

> > NOBODY
>
> Nobody wanted ImportC, either. However, several people have 
> told me that they have been seduced into using it and found it 
> delightful and very productive. Heck, in another posting I 
> discovered it could be used to translate C code to D!

1) Everybody wanted a way to import C directly. It's been 
probably the most requested language change for D ever. ImportC 
is turning out to be a great success, and I think it will change 
D's future for the better.
2) People can and do successfully and joyfully use printf. Nobody 
is asking for more printf capabilities.
3) YAIDIP and DIP1036 cover this mechanism way way better than 
DIP1027 or some special case compiler workaround would.

-Steve