DIP 1027--String Interpolation--Final Review Discussion Thread

[Steven Schveighoffer]

On 2/4/20 6:03 PM, Adam D. Ruppe wrote:
> On Tuesday, 4 February 2020 at 18:41:20 UTC, jmh530 wrote:
>> Under the addendum proposal, is it also the case that functions that 
>> take strings or printf can instead take the interpolated string?
> 
> That would depend on the druntime implementation. I think my preference 
> would be it implicitly casts to string and const char* if and only if 
> all format specifiers are given by the user.
> 
> I just wrote up a revised DIP based on Walter's to detail my current 
> thoughts:
> 
> https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f
> 

Thanks for writing this up.

A few things:

0. You have missed one edit:

* `'$' '{' FormatString '}' Argument`, then 
`_d_interpolated_format_spec(FormatString)` is written to the output string.

Should say "is appended to the argument list"

1. I hate that this doesn't work:

alias toFormatString!null this

I did some investigation. The compiler treats enum'd strings as 
convertible to const char * in many cases but not all. For example:

enum str = "hi\n";
enum str2 = "hello " ~ "world!\n";
enum str3 = text("hello", " world!\n");

printf(str); // ok
printf(str2); // ok
printf(str3); // nope

IMO, this is a bug, no reason not to make this consistent.

So I thought I would make a fancy mixin that generates the enum string 
from a tuple of strings using only concatenation. It works!

But then I ran into another problem -- namely that alias this somehow 
removes this ability to auto-convert to const char *.

This seems like another bug to me, and a limitation that we should fix.

BTW, I really like that you give the library writer the ability to alter 
the default spec so easily. Writing small shims should be trivial.

2. I disagree that you shouldn't be able to do writefln(i"someint : 
$someint") without adding an overload to writefln. That is the one 
benefit of Walter's proposal that I like -- you can use it out of the 
box with existing functions.

I know it means you have to be aware of the problems that can occur, and 
understand how the lowering actually works. But there are going to be 
quite a few functions that exist already with this kind of mechanism, 
and I don't want to make all those functions inaccessible except via 
adding overloads.

But your CreateWindow example is also pretty compelling. It would be 
nice to make "send the first parameter as a string" opt-in. Is there a 
way we can do that without requiring overloads?

3. I'm also not sold on the "if they provided a format specifier, they 
know it returns a tuple" logic. Plenty of existing string interpolation 
libraries provide ways to format the parameters into strings, and still 
can be used as strings.

Note that C# does something pretty cool [1] (as I just looked it up to 
see what other interpolation libraries do): if the interpolation is 
intended to be used as a string, it lowers to a call to String.Format. 
If its type is going to be IFormattable or FormattableString, it 
generates a structure not dissimilar to what we are wanting here [2]. So 
there is kind of a precedent for this feature in other string 
interpolation implementations.

I'm not sure whether we can provide this level of seamlessness without 
return type overloads, but I like the idup idea, and I still think we 
shouldn't call this feature string interpolation, due to the existing 
expectation for "string interpolation". Inspired by that C# type, maybe 
"formattable tuple" is a good description.

-Steve

[1] 
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated#compilation-of-interpolated-strings
[2] 
https://docs.microsoft.com/en-us/dotnet/api/system.formattablestring?view=netframework-4.8