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

[Max Haughton]

On Sunday, 31 January 2021 at 15:54:38 UTC, Andrei Alexandrescu 
wrote:
>> Try to please everybody and you end up pleasing nobody.
> ...
>> DIP1027 works with writef, and I consider that to be the goal, 
>> not printf.
>
> Unpopular opinion follows (at this point I have no idea which 
> side of the debate this puts me on).
>
> I think working with either writef or printf is a bit of a side 
> quest, and to the extent it affects the fundamental design it 
> becomes a nongoal.
>
> The printf family (which includes writef, too) has a 
> fundamental characteristic: the formatting specification are 
> SEPARATE from the data. You pass the formatting template, you 
> pass the data, and the function puts them together and produces 
> a string nice. This way of doing things has pluses and minuses 
> that are well known.
>
> Interpolated strings fundamentally do the converse: they MIX 
> the formatting specification with the data. You see bits of 
> literal strings mixed with pieces of data. That, too, has 
> pluses and minuses.
>
> From that vantage point, I look at the effort of supporting 
> {print,write}f in interpolated strings leading to any number of 
> contortions and come and ask: cui prodest? Indeed, cui the heck 
> prodest?
>
> The main client of string interpolation by A MILE, is code 
> generation. Whether it's D code, SQL, your own embedded 
> language - that's the ONE use case that any DIP proposing this 
> should drive with. Supporting (print|write)f is some weird 
> invention - I already have these functions that separate 
> formatting from data, why do I want to transform the converse 
> way of doing things into this?
>
> But wait! one might say in response. What if I need on occasion 
> some special formatting of one argument in one of them nice 
> interpolated strings? No problem, I say. Do what Perl, PHP, and 
> Python programmers have done for millenia - apply the 
> formatting function separately for the desired argument:
>
> i"Hello, ${format(`%45s`, var)} world"!
>
> That's how the cookie crumbles. To have to pay syntactically 
> and in complexity WHENEVER I EVER use an interpolated string on 
> the off chance that I might need special formatting for ONE 
> argument is unconscionable.
>
> Define interpolated strings to be simple, cheap, obvious, and 
> well fit for their MAIN USE CASE, which is code generation.

Isn't the specific formatting for a given argument mainly for 
things like floats in practice? We have good ways of doing this 
already, I think if any given proposal is merged it seems worth 
holding back and collecting experience before standardising 
anything other than calling format yourself (What alternatives do 
you have in mind? - the solution I see in python looks fairly 
arcane)

But I (intensely) agree that printf really doesn't matter here - 
even talking C, puts surely is the closest analogue.