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

[Avrina]

On Tuesday, 8 September 2020 at 13:32:10 UTC, Steven 
Schveighoffer wrote:
> 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.

That doesn't answer the question. A type map to specifier would 
do the same thing, just better; actually doing the work for the 
user.

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

The way you have to pass the interpolated string for it to work 
makes it almost completely useless. Requiring all format 
specifiers to be defined by the user is counter intuitive 
compared to using an overload. There are many C libraries, they 
require you to write bindings in D anyways, it would not be that 
difficult to add an overload for interpolated strings.

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

The DIP lists one? The CreateWindow example, if the specifier is 
given, you can call a function with the wrong arguments that 
weren't intended. The only way to avoid this is if you 
specifically create an overload to avoid the implicit conversion. 
This should not be the default.

If there is any implicit conversion happening for an I 
telrpolated string, the only valid case would be one where it is 
converted to the finalized string. Which isn't possible the way 
this is being implemented.

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

Not sure what you are getting at here. You seemed to have taken a 
paragraph out of context on which it was written.

It shouldn't provide any formatting at all. See the below 
statement you cut off.

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

Yes, and the features they provide is what should be removed. 
There's no point to being able to call a C function with an 
interpolated string without an overload, see above.

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

The sequence is accessible publically, at least with the given 
implementation as it is just a template. If that is not currently 
intended then the DIP implementation should be fixed, and that 
makes the situation with the 'toFormatString' default specifer 
much much worse. The user is forced to use it and can't implement 
their own type map to specifier to make interpolated strings 
function without having to have the user forcibly put specifiers 
in their  interpolated strings for types that don't match the 
default.

> 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

It'd be better if this wasn't accepted then, rather than adding a 
crippled feature that's counter intuitive for a user to use.

The discussion of the feature proposed was promising in the other 
DIP threads. What this ended up being isn't all that different 
than the other DIP.