DIP 1027--String Interpolation--Final Review Feedback Thread
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
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
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
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
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
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
> 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
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