DIP 1027---String Interpolation---Format Assessment

[Adam D. Ruppe]

On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
> This may have already been answered in the other threads, but I 
> was just wondering if anyone managed to propose a way to avoid 
> this scenario with DIP1027?

Yes, that is the key impetus of our amendment, which I also wrote 
up on a gist weeks ago.... and it is now on github too! 
https://github.com/dlang/DIPs/pull/186

By putting a new type around the generated format string, the 
f(i"") is a type mismatch error, so the user can decide what they 
want to do (I propose having the compiler suggest you call 
`.idup` on it to copy it into an ordinary GC string for new users 
to quickly get going with it.)

That's all our amendment fundamentally does.

Walter's: i"test $foo" -> "test %s", foo
Our's:    i"test $foo" -> wrapper!("test ", thing(null)), foo

The `thing` there represents the interpolated item and 
user-defined format string. Since there isn't one, it is passed 
null.

The `wrapper` there is a new type.


Both `thing` and `wrapper` are defined by the language and their 
actual implementations live in druntime

struct thing { string specifier; }
struct wrapper(format_string_pieces...) {}


 From the language perspective, the rest is the same was Walter's 
proposal. Just with that wrapper type:

foo(string, int) // type error, cannot convert wrapper to string

to protect from that.