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

[Ola Fosheim Grøstad]

On Wednesday, 11 December 2019 at 13:43:48 UTC, Adam D. Ruppe 
wrote:
> On Wednesday, 11 December 2019 at 11:21:08 UTC, Ola Fosheim 
> Grøstad wrote:
>> Agree. Your suggestion is much more in line with 
>> metaprogramming and offers the right flexibility.
>
> But then it is impossible to tell which parts were in the 
> string literal and which parts are outside data.

Can't you handle this by taking the head of the tuple and then 
let the formatter absorb what it needs? Then continue with the 
rest of the tuple?

Anyway, that was just a suggestion for making something that was 
close enough to Python 3 to be easy to use for simple cases (but 
slightly more difficult for advanced meta programming).

No problem with clever tricks in libraries, but it should not be 
complex on the surface, like this DIP. D needs to 1. embrace 
metaprogramming and 2. provide a simple surface for newbies.

> If you are going to do the tuple thing it absolutely must put a 
> string in every other slot so this can be predicted.

Not necessarily, if you have a protocol then you can identify the 
type. However, it is probably better to let the formatting object 
wrap the data.

If you want it simple: add tuples. You either get something that 
can be turned into a string or you get a tuple, if you get a 
tuple then the first item in the tuple is a formatter and the 
rest is data.

Probably 100 ways to do this, but the key is to support custom 
formatters in an efficient manner that does not require high 
level allocation optimizations (GC languages can optimize away 
allocations because they control the allocator and all 
allocations).