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

[Walter Bright]

On 12/16/2019 6:00 AM, Nick Treleaven wrote:
> On Monday, 16 December 2019 at 13:22:45 UTC, Atila Neves wrote:
>> On Monday, 16 December 2019 at 10:48:51 UTC, aliak wrote:
>>> User: why can't I do this?/Why doesn't this work?
>>>
>>> string s = i"$var";
>>>
>>> Answer?
>>
>> import std.format: format;
>> string s = format(i"$var");
> 
> That isn't an answer to the question, it's just a workaround. 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:

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

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.

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

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

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

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.