DIP 1027--String Interpolation--Final Review Feedback Thread

Arine arine123445128843 at gmail.com
Fri Jan 31 05:44:03 UTC 2020

This is purely feedback (please state why it was removed):

1) Format string with args in a tuple is *not* easy to manipulate.
2) A false statement is made in the DIP, this needs to be fixed.
3) A change was made that allows error prone code that's 
difficult to detect, this should be reverted.
4) D should diagnose printf format errors, C++ does this and it 
is only a library implementation there. This DIP brings printf 
formats into a language feature.
5) The grammar of the language should be updated so we know 
exactly what printf format option corresponds to which type. Eg 
string -> %s, int -> %d, float -> %f, etc...

> The DIP author's position, established over several comments, 
> was essentially:
> tuples can easily be manipulated to suit the user's needs

I know this is just paraphrasing, but this is not true. Tuples 
alone might be easy to manipulated, but a formatted string with 
args disguised as a tuple is *not*.

Write a custom function that'd take an interpolated string that 
would otherwise remove or somehow manipulate the first argument 
that wasn't a string.

If an interpolated string simple evaluated as a plain tuple or as 
a struct (as some others have proposed). You can easy use CTFE to 
find the first argument, and then remove it or manipulated how it 
is outputted.

Because this DIP proposes using format strings, your 
implementation would have to be able to properly parse a 
formatted string. Find the argument you are looking for, and then 
proceed to remove or manipulate the formatted string to suite 
your needs so that you would then have to pass it into a 
sprintf()-like function.

That is no easy task. Especially if the expectation is that it 
should support _all_ of printf's formatting capabilities. This 
creates the expectation that a user can just pass a printf-like 
format argument with all their optional settings. If the user's 
implementation *needs* to verify the format string to be valid. 
It becomes extremely complicated and would need to be able to 
parse and understand all of printf's format syntax.

This means interpolated strings won't likely be used for anything 
except for essentially format() and printf() like functions (or 
functions that simply forward the arguments to those functions) 
that implement the format specification and don't need to 
manipulate or verify the input.

A format string isn't easily convertible back to a tuple of 
arguments where the arguments are in place of where their values 
should be in the string.

A tuple or struct (as proposed by someone else) representation of 
a interpolated string is easily convertible to be used in a 
printf-like function.

     i"hammering $object with $tool"             // becomes
     tuple("hammering %s with %s", object, tool)

     // which is difficult to convert back to:
     // (especially since the expectation is to support all of 
printf's syntax)

     tuple("hammering ", object, " with ", tool)
     // but the above can easily be turned into the 
printf-formatted tuple above

A tuple/struct interpolated string (without printf-like 
formatting) has all the benefits as described but it is much much 
easier for the user to manipulate and work with. And doesn't 
create an expectation to support all of printf's formatting 
syntax when it shouldn't be necessary. And it can easily be 
converted to be used with printf.

> The meaning of the format specifications is unknown to the core 
> language.

This statement is just false and should be removed from the DIP. 
If it doesn't know anything about the format specification then 
the DIP with its' current proposed implementation wouldn't be 
able to function.

> Mixing Conventional Format Arguments With Interpolated Strings
> Interpolated string formats cannot be mixed with conventional 
> elements:
>     string tool = "hammer";
>     writefln(i"hammering %s with $tool", "nails");

Not sure why this is now allowed. This just makes it difficult to 
see that something went wrong. Especially so if you are using 
printf()/scanf() and you mix up two incompatible types, like a 
string. This just adds unnecessary risk for very little gain. 
(And it seems the intention is to not analyze the formatted 

> No attempt is made to diagnose format specification errors, 
> such as attempting to format an integer as a floating point 
> value.

If you are going to make this feature part of the language, then 
it should diagnose it. Even C++ compilers analyze it to ensure 
you are using printf correctly. That language doesn't even have 
it as part of a language feature. It is just a library detail 
implemented as part of the C standard library. If D is going to 
embed printf formatting details as part of the core language 
specification, then it should at the very least be capable of 
analyzing the format it is going to be forcing onto everyone that 
wants to use interpolated strings.

More information about the Digitalmars-d mailing list