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

[Jacob Carlborg]

On Monday, 16 December 2019 at 21:42:32 UTC, Walter Bright wrote:

> 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.

It doesn't need to go directly to a string. Just the end result 
needs to be a string. In Swift they achieve this by lowering the 
string interpolation to a set of method calls:

"The time is \(time)."

Is lowered to something like:

var interpolation = MyString.StringInterpolation(literalCapacity: 
13,
                                                  
interpolationCount: 1)

interpolation.appendLiteral("The time is ")
interpolation.appendInterpolation(time)
interpolation.appendLiteral(".")

MyString(stringInterpolation: interpolation)

These methods are overridable to be able to customize the 
behavior.

--
/Jacob Carlborg