Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2

[Walter Bright]

On 1/29/2021 9:18 AM, Steven Schveighoffer wrote:
> On 1/29/21 3:02 AM, Walter Bright wrote:
>> On 1/28/2021 8:47 PM, Adam D. Ruppe wrote:
>>> D excels at these things.
>>
>> Ok, it's doable, but it's writing your own printf to do these manipulations.
> 
> It's doing what you want because it's possible. When someone says "yeah but I 
> can't do this", and I say "OK, here's a wrapper I wrote in 15 minutes that does 
> what you want" and you say "But that means I need a wrapper!", I don't really 
> know where to go from here. You asked for something that works with printf, I 
> gave it to you. If you don't like it, I don't know what to say, but it's 
> trivially easy and can be inlined to a direct call.
> 
> What if I complained that @safe feature is unusable because I had to wrap the OS 
> `read` as a @trusted function? Would that be a reasonable argument? It requires 
> a simple wrapper, write it and be done. Or don't use @safe code.
> 
> In fact DIP1027 CANNOT make an overload for printf that's usable in D code, and 
> the existing printf can't be used with strings (ironically the default specifier 
> for DIP1027) without horrible syntax.
> 
> If you want to use printf without a wrapper, use printf as it was intended. If 
> you want to use printf with interpolation strings, use a trivial wrapper.

It's simply that if I want to use it with printf, I have to write my own printf 
intermediary. That's not using it with printf. It's kinda trivially obvious that 
someone can write their own functions to do things, but pretending it is printf 
by naming it printf just puts a layer of confusion in for the reader. printf is 
so ubiquitous that it brings expectations when saying printf can be called that 
printf is actually being called, rather than some intermediary one must write 
oneself. Personally, I'd reject any PRs that contained an overload for printf or 
any other member of the C Standard Library.

The same applies to the mysql example in the DIP - the user has to write their 
own intermediary to get it to work.

Also, needing the GC for this to work with printf is a problem, as one cannot 
use it with betterC. Having this GC call hidden is not good, as D programmers 
calling printf are likely doing it because they want the low overhead and 
predictable behavior that printf provides. (I'm actually not sure if the GC 
would be required for the printf intermediary, which is another problem, as it 
isn't obvious when it is needed or not.)