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

[Paul Backus]

On Friday, 11 September 2020 at 19:04:23 UTC, Adam D. Ruppe wrote:
> The complexity of the format spec may seem superfluous, however 
> it serves four key roles:
>
>     1. It divorces the compiler entirely from details of 
> generated format strings. For example, different functions that 
> accept format strings might use different default format 
> specifiers.

A much easier way to do this is to simply have no default format 
specifier in the first place. This is how f"..." strings would 
work in my proposal. (Though I agree this was an issue with DIP 
1027.)

>     2. It allows overloading existing string-accepting 
> functions to prevent accidental usage that happens to fit the 
> parameter list (see example below).

If a function is prone to accidental usage with string 
interpolation, it's probably also prone to accidental usage 
without string interpolation. The solution is to use the type 
system. Again, I refer you to Scott Meyers for a more detailed 
explanation:

https://www.youtube.com/watch?v=5tg1ONG18H8&t=47m15s

>     3. It provides necessary error checking capabilities.

Not sure what you mean by this. The Phobos functions that use the 
existing argument-list conventions already do error checking; is 
there something they're currently missing?

>     4. It provides an additional API for user functions to 
> introspect the string, building on D's existing compile-time 
> capabilities.

We can already do this with existing D features. See for example 
`std.format.format`, which has an overload that introspects the 
format string at compile time.