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

[Steven Schveighoffer]

On 2/5/20 1:07 AM, Walter Bright wrote:

> 3. having the interpolator escape % by writing %% means that % becomes 
> "baked in" as a special character. This is a completely unnecessary 
> complication.

I want to respond to this point because I feel you have misunderstood 
the point of my rationale in the modification I proposed.

I do NOT want the compiler (or the runtime) escaping anything. I want 
everything to go in as-is.

However, the function which is called with this information CAN treat it 
differently if desired. For example (and this is just an example, not a 
requirement or expectation), we could pretty much make the `f` versions 
of write obsolete, as having the formatting done by string interpolation 
can simply be put into the non-f versions.

Example:

writeln(i"your hex data is ${%02x}someByte");

There's no need for the 'f' version of writeln there if the interpolated 
string format is not just a basic string, and recognized specially by 
writeln. Not only that, but if you did need to put interpolated strings 
later in the parameter list (which would now be possible), the "just 
slap a format at the end" is a horrible alternative, because it means 
you are allocating a string just to print stuff. This is providing more 
efficient code.

AS A BENEFIT, in this instance, writeln can simply ignore any % that is 
in the string part of the format string in terms of a formatting 
specifier. This is so much cleaner, as 1) no matching of format 
specifiers to parameters need take place, the compiler has already done 
that work, and 2) the code actually doesn't have to parse the non-format 
parts of the format string AT ALL.

In other words, I don't want the compiler or runtime knowing ANYTHING 
about formatting or the specific formatting specifiers required for 
formatting strings for any call (thank you for making that possible by 
passing the format specifier as-is). I just want it to be POSSIBLE to 
treat that differently than "all % in the first parameter are meaningful".

I LIKE the DIP in that it gives you instant compatibility with existing 
format + args calls. That's its hallmark feature. I wouldn't want to 
change that, as instantly, you can start using it with all your code 
base with just cleaner-looking calls. But IMO we can and should do 
better to allow library writers the benefit of the compiler's knowledge.

> ----
> 
> The DIP is minimalist. This is intentional, as it proposes a very simple 
> and straightforward rewrite of a literal into a tuple expression. 
> Understanding tuple expressions (an existing D feature) is essential to 
> understanding the DIP. This is a technique called "lowering" and is a 
> great way of simplifying the semantics of a language and reducing corner 
> cases and implementation bugs. Other examples:
> 
> 1. the compiler rewrites 'while' loops into 'for' loops
> 
> 2. the compiler rewrites RAII constructions into `try-finally` 
> constructions
> 
> In fact, the compiler could profit from doing a lot more lowering 
> transformations.

The additional proposal isn't any less minimalist. All you are doing is 
transforming the format specification into a tuple instead of a string. 
I bet the code isn't even any more complicated.

When I think about existing D features, to me the additional proposal is 
akin to the transition from opAdd, opMul, opSub, etc to opBinary!(string 
op). The power realized there can be realized here as well. The more 
things you give people to play with at compile time, the more efficient 
the code can be, the more specialized people can do things.

Consider this -- we can do compile-time checking of format strings 
outside the compiler with this feature at any later time. Again, with 
minimal effort, as parsing the format string for valid % tokens isn't 
necessary.

-Steve