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

[Steven Schveighoffer]

On 12/14/19 9:23 AM, Adam D. Ruppe wrote:
> On Saturday, 14 December 2019 at 09:10:47 UTC, Walter Bright wrote:
>> I find your proposal a little confusing. By turning the string into an 
>> object, it doesn't work with printf?
> 
> Right, not directly. But then it is trivial to add a member of the 
> object that transforms it into a tuple suitable for printf.
> 
> So the end user's code now looks like: `printf(i"foo %bar".asFormatTuple);`
> 
> BTW I am not opposed to your version either, since it can be transformed 
> into something close to my version. My big concern is that your version 
> (as well as Jonathan Marler's) loses information very easily.

What information does it lose?

> printf(i"%item"); // happens to work
> writefln(i"%item"); // also happens to work
> 
> writeln(i"%item"); // oops! not going to do what you want

But did what you asked? Coding is full of such dilemmas. I've actually 
done this many many times:

writeln("Value is %s", value);

I see the result, and fix it. This isn't difficult.

One other suggestion I had was to make the resulting string literal 
generated by interpolation be a derivative of a string literal. That is, 
it's usable wherever a string literal is, but functions that wish to 
overload based on that type difference can do so.

i.e. we could make the writeln call above work as expected.

> 
> format(); // works
> text(); // wrong
> 
> And there's no compile error for incorrect usage. With an object, we get 
> existing type checking safety and can guide it to the correct usage:
> 
> printf(i""); // error cannot implicitly convert __d_interpolated_string 
> to const char*

Hm... I prefer it just working correctly.

> 
> writefln(i""); // static assert failed: "use i"".asFormatTuple instead

Same. But why wouldn't writefln be overloaded on your object type to do 
the right thing?

> 
> writeln(i""); // happens to just work because it calls toString

Sure, but if you are going through the trouble to deal with format 
specifiers, I don't know why you'd want to support writeln out of the 
box but not writefln.

Not only that, but now you have to pull a lot of the library into 
druntime (std.format for example).

>> I'm also not sure it's a good idea to make this more powerful. As a 
>> simple "replace the string with a tuple" its very easy to understand.
> 
> Objects are easy to understand too. And easy to implement: on the 
> compiler it is basically just `X!(your version)` instead of just plain 
> `(your version)`.

What about the lifetime issues? An object is going to make a copy. Which 
may not be correct or possible.

I do like two aspects of your proposal. First is that all the 
information is available for further compile-time manipulation. Second 
is that having a specialized type allows function overloading.

-Steve