String Interpolation Compare - DIP1027 and YAIDIP

[Adam D Ruppe]

Note to readers: you don't have to believe second-hand nonsense. 
There's functional implementations to play with already:

YAIDIP's first draft itself: 
https://github.com/dlang/dmd/pull/15714

YAIDIP is not perfect, so I made a better iteration on the 
concept too:
https://github.com/dlang/dmd/pull/15715

Some things in there could still be changed, of course, but even 
in its current draft state, you can easily see what is true and 
false in these comparisons.




On Saturday, 21 October 2023 at 01:50:33 UTC, Walter Bright wrote:
> YAIDIP generates a template instance followed by a sequence of 
> string arguments.

Not true. The only string arguments are the strings interpolated 
with the arguments.

> 2. It's inefficient because it requires the arguments to be 
> converted to string temporaries, and then the strings are 
> appended to the result.

Not true. You have shown zero understanding of what it is, even 
though there's an implementation you could look at in addition to 
the document!

>     i"axy:  $leadingZero$digits(3)$a $scientific$x 
> $fixed(20,10)$y" // YAIDIP

This is one possible use case of it, but there's several others, 
including using format strings. It is 100% up to the library what 
to do; the compiler is agnostic to these specifics.

> 4. If the manipulators are not in scope, there's no way to 
> qualify them with the '.' syntax. Temporary aliases are 
> necessary:

Not true. This might be the stupidest of your ignorant 
statements, since even basic knowledge of how D modules work show 
your examples are nonsense (you can `import std.istring;`!), and 
if you read the DIP or played with the implementation, you'd also 
know you can enclose a fully-qualified name in parenthesis too.

> 5. The tuple output, which the user is sooner or later going to 
> be confronted with, looks like (copied from YAIDIP):

This is half true. We could make the compiler error messages 
nicer with a bit of implementation effort, but currently they 
messages do indeed look like:

test.d(51): Error: function `test.foos(string s)` is not callable 
using argument types `(InterpolationHeader, 
InterpolatedLiteral!"Hello, ", InterpolatedExpression!"name", 
string, InterpolatedLiteral!"", InterpolationFooter)`
test.d(51):        cannot pass argument `InterpolationHeader()` 
of type `InterpolationHeader` to parameter `string s`


>     writefln("%s can be written as %e or %20.10f", x, y);

But this is still a dishonest comparison. If you passed that to a 
`void foos(string s)` you'd get an error message along the lines 
of:

test.d(52): Error: function `test.foos(string s)` is not callable 
using argument types `(string, string)` test.d(52):        
expected 1 argument(s), not 2

Which would still require the user to understand how the thing 
works, since if they are thinking they ARE passing a string, 
they'd wonder why the compiler thinks there's two.

> 6. It requires another template added to object.d, which is 
> already so bloated with templates it consumes a large compile 
> time penalty. It requires the user to understand this template.

Not true.

> 7. It requires the creation of another module, call it 
> `std.istring`, to contain all the manipulators a user will 
> expect to see (such as `scientific`).

Not true. (But this is an option, but it is not a requirement).

> 8. There will be difficulties using this with betterC because 
> of the required string allocations mentioned earlier.

Not true.

> 9. i-strings are special case behaviors for pragma, mixin, 
> assert, static assert, function calls, constructor calls, and 
> template instantiations. They are not general purpose. They 
> cannot be used for things like generating tuples for other uses.

Half true, they would be special case for pragma, etc., if you 
wanted to (I don't btw, I'd tell the user to call the function), 
but they *can* be used for other users. THAT'S THE WHOLE POINT.

> # DIP1027
>
> # Pros
>
> 3. does not require a library of manipulators

Not true - that library is `format` or `printf` etc., but it is 
there.

Of course, the other proposal also works with those functions. We 
even provided implementations - it is a short function. One short 
example is here: 
https://github.com/dlang/dmd/pull/15715#issuecomment-1773146760

> 5. can do everything YAIDIP does

Completely and utterly false, as we've gone over many, many, many 
times.

> 10. the i-strings are much more compact

False.

> 11. generates a tuple that is self-evident

That's just like, your opinion, man.

> 12. generates a tuple that can be used anywhere tuples work

False.

> # CONS

> 1. Is more susceptible to inadvertent matching with the wrong 
> function, because the tuples generated are tuples of strings, 
> integers, and other ordinary types.

Hey, you finally said something that's 100% true!


Again, to see the truth, look at the implementations:

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

And a better iteration of the concept:
https://github.com/dlang/dmd/pull/15715

DIP texts are hard to read. Experimenting with it is easy. Don't 
believe second-hand nonsense.