DIP 1027---String Interpolation---Community Review Round 1

[mipri]

On Wednesday, 11 December 2019 at 09:52:21 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community 
> Review for DIP 1027, "String Interpolation":
>
> https://github.com/dlang/DIPs/blob/148001a963f5d6e090bb6beef5caf9854372d0bc/DIPs/DIP1027.md
>

Questions for the rationale:

1. Why % as a format character?

I would guess "so that legacy strings won't accidentally
trigger interpolation", but since this proposal already
requires i"" syntax, legacy strings aren't a problem.

Or "wanting to specify the formatting, as with %{d}bananas,
meant I had to come up with something new anyway." But Nim,
Zig, and Python all do this (the first two as normal library
functionality rather than a language extension) with the {}
syntax.

   import strformat
   let num = 123
   echo fmt"{num}"    # output: 123
   echo fmt"{num:x}"  # output: 7b

Alternate syntax ({} interpolation):

   writefln(i"I ate {apples} and {bananas:d} totalling {apples + 
bananas} fruit.");

2. Why i"" syntax?

It (presumably, not necessarily) conflicts with user string
prefixes, and since this proposal already limits string
interpolation to printf-style uses, and since the use of %
format character already makes conflict with legacy strings
already very unlikely, why not use regular string syntax but
make writefln() and friends statically analyze the string
they're given to see if it's an interpolating one or not?

Alternate syntax (no i""; in(isTemplated!argstring)):

   writefln("I ate %apples and %{d}bananas totalling %(apples + 
bananas) fruit.");

3. Why rewrite to positional code?

I would guess "because I don't want to add new GC-reliant
features", but since this proposal already limits string
interpolation to printf-style uses, the function accepting the
string is an obvious owner.

The positional rewrite has other problems:

a. interpolated strings can't be mixed with conventional
elements, a common and unremarkable thing for interpolation in
other languages.

b. functions that accept an interpolated string have to know
that they do this, and have special handling for it, when in
other languages the choice to interpolate is purely a decision
of the caller's, and can be changed for readability or
efficiency or taste.

c. Speaking of efficiency: in other languages you can hoist a
repeated use of an interpolated string above some loops that
use it. With this proposal you'd have to rely on the optimizer
to deal with this.

4. Seriously, why rewrite to positional code?

This is going to function as something like an attractive
nuisance for people that learn D.

Newbie: "Hey, I want some interpolation here. Does D have that? 
Oh! It
does!"

Newbie: *uses interpolation, gets error*

Newbie: "what?"

Newbie: ... this D thing, it's filled with features with
strange limitations. Features that don't work naturally
together. Come on even a simple thing like string
interpolation! That's convenient in every language that has it!
Why is it so weird here? This is just like how the other day I
tried to rewrite a trivial benchmark in -betterC and kept
getting weird errors about TypeInfos. grumble grumble grumble.

*** meanwhile, in a world without interpolation ***

Newbie: "Hey, I want some interpolation here. Does D have that?
... looks like format() does what I want."

Newbie: *uses format(), it works as expected, life moves on*

--
Final "but since this proposal already" count: 3