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

[Nick Treleaven]

On Monday, 16 December 2019 at 21:42:32 UTC, Walter Bright wrote:
> On 12/16/2019 6:00 AM, Nick Treleaven wrote:
>> Interpolated strings could implicitly convert to strings, 
>> which is the most common use case in typical D code. That 
>> would not bloat code that doesn't need it, as Adam has shown 
>> by using an import inside a template.
>> 
>> Interpolated strings should not be designed with low-level 
>> concerns as the priority motivator at the cost of high level 
>> usability and safety.
>> 
>> D is supposed to be a type safe language, even 
>> std.format.format is not fully type safe because using string 
>> for a format string allows runtime errors.
>> 
>> Any good D interpolation proposal would support compile time 
>> checked format strings, even when runtime arguments are 
>> passed. D is supposed to be the best language for compile time 
>> stuff!
>
> Having it go directly to a string has multiple problems:

I said implicitly convert. If it lowers to a templated struct, it 
can still be used without converting to string - see below.

> 1. Those who want the tuple in order to do something else with 
> it will be unhappy and out of luck.

struct FormatSeq(S...)
{
     /// the sequence for e.g. printf
     S expand;

     alias get this;

     @property string get()() // template, doesn't link Phobos 
unless needed
     {
         import std.format;
         return format(expand);
     }
}

unittest
{
     int i = 5;
     string s = "hi";
     //auto fs = i"$i, $s";
     auto fs = FormatSeq!(string, int, string)("%s, %s", i, s); 
//lowering
     import std.stdio;
     writefln(fs.expand); // works as format string
     string s2 = fs; // works as string implicitly too
     s2.writeln;
}

> 2. It will not work with betterC.
> 3. It will allocate GC memory.
> 4. It will be substantially slower because of the extra 
> intermediate buffer.

None of these points are true, just use `.expand` and avoid the 
alias this.

> 5. I don't think it'll work with Steven Schweighoffer's SQL 
> examples.

The above get method would do the wrong thing, yes. Perhaps if 
the format string is a struct template value parameter, the code 
can detect that custom specifiers have been used and statically 
disable the get method.

> 6. It will require the core language to depend on a rather 
> large and complex Phobos routine.

Only if the alias this is actually used - it's a template. The 
precedent for lowering to Phobos is the ^^ operator which IIRC 
lowers to std.math.pow.

> 7. It will not be any more typesafe than it would be generating 
> a tuple.

The common case for creating a string is seamless and can't be 
done wrong when using alias this, which is also the easiest way 
to use it. printf could be wrapped with a method, and the format 
string could be checked at compile-time when it's a literal.

> 8. The number of times I've wanted a formatted string as the 
> end result, as opposed to wanting formatted insertion into 
> something else, is about 1 in 100, if that.

So just put .expand after the interpolated string. For *every* 
programming language I'm aware of, interpolated strings 
implicitly convert to a string.

If it really is as commonly needed as you think, you can add 
wrapper methods to the struct so you even avoid importing 
core.stdc or std.stdio.