Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[Steven Schveighoffer]

On 9/8/20 8:10 AM, Avrina wrote:
> What's the purpose of toFormatString with a default spec? Why would you 
> ever want to have a default??? That's just some hacky workaround from 
> the previous DIP to circumvent some arbitrary rule. Why wouldn't you 
> have some sort of type map instead that maps a format string to a type? 
> All of that information is available.

Because the default spec should not be constrained by the language (e.g. 
always "%s" as DIP1027 specified). See for instance mysql prepared 
statements, where the spec is "?". This way the callee can decide what 
to put for default specs.

> 
> The way 'hasAllSpec' seems to be intended to use just seems terrible. 
> What happened to having an overload for printf() to handle the case of 
> an interpolated string. Is that overload not happening?

We could potentially handle it that way. But the idea of not having to 
handle it that way for this case is appealing. It means we don't have to 
write an overload for it unless you want to. There are potentially quite 
a few C libraries that use the format + parameters mechanism, and this 
allows a way to call those without having to write a wrapper for it.

> Implicitly 
> converting to char* on a condition like 'hasAllSpec' is just asking for 
> trouble. This special case isn't required, it will only introduce bugs; 

All vague statements, do you know of any specific trouble or bugs?

> just add an overload to printf. It also requires the user to specify all 
> the formatting themselves when all that information is already there for 
> it to know what formatting specifier to use. That wouldn't fly in a 
> intrrolated string library implementation and it definitely shouldn't 
> fly as a language feature.

This DIP doesn't provide for matching of parameters to their respective 
formats. It is one step above DIP1027, in that it allows a callee to 
specify the default format, and the format is available at compile-time. 
The main benefit is simply the fact that you CAN overload based on the 
fact that you received an interpolated string.

> 
> The 'toFormatStringImpl' and friends implementations should just be 
> removed. Its simple enough that anyone can implement it, not.like there 
> is a performance benefit anyways as it is just going to be using CTFE, 
> like a library implementation. It is also too specific, something like 
> an sql query would just put a number depending on the order of the 
> parameters. So in that case it isnt really a specifier for the argument 
> some much as which argument should go where. I can only imagine how 
> confusing and error prone that is going to be, especially since you have 
> to specify every single argument if you dont implement your own wrapper 
> or overload to fix this.

These are implementation details, and not necessarily the final 
implementation. The real API is specified in the description.

The numbered SQL problem is definitely one that is troubling -- you have 
to put in a placeholder for the number, and then replace it with the 
correct value, which means 2 passes of compile-time string generation. 
However, this is something that could be improved upon if the type 
provides access to the raw spec sequence, or allows a different way to 
build the format string (I have some ideas).

Note that we are trying to prevent people from abusing the 
implementation to achieve "AST Macros" as Walter likes to put it. If we 
can provide a better way to generate the formatting, and still keep this 
property, it has a better chance of being accepted.

-Steve