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

Jab jab_293 at gmall.com
Tue Dec 17 16:10:24 UTC 2019


On Tuesday, 17 December 2019 at 06:15:03 UTC, mipri wrote:
> 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?

Sorry I forgot to go back and edit this after I changed it. It be 
more complicated as instead of just using "?" it would have to be 
able to know about and parse printf-style formatting.

>>>   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

Ok? I've literally never seen this function used in any software. 
Probably for a good reason.

>> 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.

The date was just illustrating the problem. Sentence structures 
in languages change, the order isn't the same in every language. 
If your using printf, localization probably doesn't matter. Your 
going to have more problems with localization using printf. If 
localization matters, there's better methods for achieving it 
than using printf and something like gettext().

>> 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.

That's the problem. This is intended to be used for printf() as 
well, but to do that you have to do something like this then:

     printf(i"blah blah ${myType.toString.toStringz}");

It becomes useless here. You are going to have to use something 
else anyways because it starts to fall apart when you try and 
support an old method like printf.






More information about the Digitalmars-d mailing list