DIP 1027---String Interpolation---Community Review Round 1

[mipri]

On Tuesday, 17 December 2019 at 05:37:53 UTC, Jab wrote:
> On Monday, 16 December 2019 at 22:48:30 UTC, mipri wrote:
>> Well-written database code in these languages is therefore
>> written as if string interpolation is not a feature of the
>> language:
>>
>>   $db->query("INSERT INTO names VALUES (?)", "Bob");
>
> This would push the complexity onto the query implementation.
> As now it has to be able to parse the string.

What?

This is how query implementations work right now. Yes, the DBMS
needs to be able to parse SQL.

Have you spoken to a database without an ORM before?

>>   printf(gettext("Hello, %s!"), name);
>
> This would usually be a warning/error in C/C++ compilers as you
> aren't using a constant string for the format.

https://www.gnu.org/software/libc/manual/html_node/Translation-with-gettext.html

> Ultimately this doesn't really help with localization either.
> What if you need to change the order? Languages have different
> ways of formatting. Maybe not the best example, but say you
> have "$year-$month-$day", but in a different location it is
> more common to do "$month-$day-$year". The gettext() can't do
> anything about that, cause it'll always have to be "%d-%d-%d",
> it can't rearrange the order.

"This doesn't help."

is not supported by

"I can think of a specific objection that internationalization
libraries definitely have specific support for."

OK, what about all the other cases? What if you format a date
using a locale-aware formatter and then just make that one of
the inputs to your format string, rather than the individual
components of the date?

It's still a better localization story than normal string
interpolation, which just has to be ripped out. You can't fix
normal string interpolation by using a locale-aware date
formatter, because the resulting string is still not something
you can look up in a translation database.

Therefore, it helps despite this objection.

Have you used gettext before?

> What happens if you want to implement your own type and pass it
> in? The DIP doesn't mention it at all.

If you're passing the i"" string to a D routine like format()
or writef(), then you get all the custom formatting that you
want, as normal. If you're passing it to a C routine or
something else, obviously you have to provide types that the C
routine can understand.

Have you printed a custom type in D before?