String Interpolation Compare - DIP1027 and YAIDIP

[Steven Schveighoffer]

On Saturday, 21 October 2023 at 06:57:30 UTC, Walter Bright wrote:
> On 10/20/2023 9:54 PM, Steven Schveighoffer wrote:
>> I'm not sure I understand this. What is `dec()`?
>
> From https://github.com/John-Colvin/YAIDIP :
>
> "Consider for example using stream manipulators such as dec and 
> hex for writeln by using an i-string:+"
>
> ```d
> void fun(int x) {
>     writeln(i"$dec$x in hexadecimal is 0x$hex$x.");
>     // Lowering: --->
>     // 
> writeln(.object.imported!"core.interpolation".InterpolationHeader!("", "dec", "", "x", " in hexadecimal is 0x", "hex", "", "x", ".")(),
>     //     "", dec, "", x, " in hexadecimal is 0x", hex, "", x, 
> ".");
> }
> ```

Oh I see now what you are looking at! This is just like C++ 
though.

```c++
std::cout << "value in hex: " << std::hex << 42
           << ", value in decimal: " << std::dec << 42 << 
std::endl;
```

`dec` is not a function that gets called on the value, it's a 
manipulator to set a flag that says "now do decimal numbers". 
It's no different for this example use case.

> And:
>
> "There is no need for defining, implementing, and memorizing a 
> sui generis mini-language of encoded format specifiers"
>
> I wasn't making false statements about that, either.

The false statement is not that these words exist in the 
proposal. It's that you have misinterpreted what these words are 
-- these things are *USE CASES* and not required for the proposal.

>>> https://www.digitalmars.com/d/archives/digitalmars/D/Just_another_example_of_missing_string_interpolation_370542.html#N370696
>> 
>> mysql requires a string as the sql for the prepared statement. 
>> Basically, you pass a string with a different type of 
>> placeholder specifier "?". It does not accept "%s". This is 
>> not something I have any control over.
>
> See my example. There's no reason it cannot be extended to 
> replace the %s with whatever is needed.

Hence, requiring allocation and runtime parsing to build the 
string.

>> So naturally, since you only get a runtime format string from 
>> DIP1027, you need to create an equivalent runtime string to 
>> pass to the library. How can you do that without allocations?
>
> The { } syntax.

No, the {} thing is a horrendous workaround. Nobody will use it, 
they'd just use the original, as this is just a large set of 
footguns that has no redeemable qualities.

Consider that for mysql there are no "format specifiers", the 
entire point for having the {} is negated because it should 
*always be* `?`. You just did `$foo` and not `${?}foo`? Sorry 
user, that's on you. It will compile and fail at runtime, or even 
worse it will succeed and do something completely unexpected. 
This is not good API design. Writing incorrect code with this 
feature is super easy and will happen non-stop. Ironically, 
printf is going to be better because it has a magic compiler 
pragma to do the things that somehow the metaprogramming 
powerhouse of D could not handle.

> But even if you needed an allocation, a malloc/free pair will 
> suffice.

YAIDIP requires no allocations, even to build a format string.

> The problem with dec() is dec() returns an allocated string, so 
> the free gets messy.

First, of course as previously mentioned, The C++ style stream 
manipulators are not a requirement of the DIP (or even proposed 
for the language). And second, as mentioned above, `dec()` does 
not allocate a string.

>>> But even if you did rewrite it, it doesn't escape the 
>>> template function, and can be RAII'd.
>> 
>> That is not comparable to building the correct string at 
>> compile-time. It also requires *parsing* the format string at 
>> runtime.
>
> I'd agree that parsing it is a last resort if the { } also 
> fails. But having implemented formatted writes, I can attest 
> that parsing it is not a big deal. It's scanning till you see 
> the %, then substitute your own version. Of course, using { } 
> means the compiler does it for you at compile time.

Of course, we can all just switch to C or assembly, what is the 
big deal? The big deal is, I have a 21st century compiler, with 
insanely good metaprogramming capabilities. I shouldn't be 
parsing strings that the compiler built at compile time to give 
me substandard information. Give me the good stuff.

-Steve