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

[Walter Bright]

On 12/14/2019 5:52 PM, Adam D. Ruppe wrote:
> On Sunday, 15 December 2019 at 01:44:18 UTC, Walter Bright wrote:
>> The extra syntax kills it
> This is true, but ONLY for the printf case. It just works in all other cases.

printf is a very important case, and it kills it for scanf and every other 
function that takes a format string (dmd itself has many printf-like functions).

>> with the extra import required, along with not working with #betterC.
> No need for import - this is a definition in object.d,

object.d is getting more and more bloated over time. This is not a solution to 
imports, and is not a good trend.


> and it will work in 
> betterC since this is a compile-time transformation (the `asFormatString` 
> definition is essentially just `template asFormatString(T...) { alias 
> asFormatString = T; }`.
> 
> And my proposal also doesn't need an import to be assigned to a string whereas 
> yours does.
> 
> string a = i""; // mine would trigger the alias toString this and just work
> 
> string a = format(i""); // must import std.format. also fails in betterC btw

betterC is for use without Phobos.

>> It's just not the default.
> Which is usable (that's why I'm not opposed to your proposal) but means it is 
> now impossible to catch accidental misuses at compile time. They type system no 
> longer helps you.

That's always been true with printf. Many C compilers have extensions to deal 
with this, but D never incorporated them (although it could).


> But what about a small compromise: what if JUST the format string was given a 
> new type and the rest was still a tuple. The format string can implicitly 
> convert to the same things a string literal can; it can go to `string` or to 
> `const char*`, but then user-defined functions are also able to overload on it.
> 
> So
> 
> i"hi %test"
> 
> becomes basically
> 
> typedef string InterpolatedFormat;
> 
> type_tuple(InterpolatedFormat("hi %s"),  test)
> 
> That'd still work in printf - it just implicitly converts back to char* - and 
> gives just enough type information hints to cover my advanced use cases too.

Adding a new basic type to the language just for this is not worth it.

With the proposal, I can explain it in one slide, which is worth a great deal.