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

[Steven Schveighoffer]

On 2/28/20 7:57 PM, aliak wrote:
> 
> I actually didn't realize it was a video, thought it was just an 
> article! - But anyway, it was just to point out that swift lowers to 
> specialized types when it comes to interpolation (which is what you and 
> adam are trying to get through). And therefor you can detect 
> interpolations being given to you and deal with them the way you want 
> and you can do a lot when you know you're getting an interpolation. You 
> can create types like
> 
> let example: SQLStatment = "select * from blah where a=\(a), b=\(b) ... "

I didn't get to this part of the video, but that is indeed pretty cool. 
I'm assuming that this generates placeholders for the SQL statement and 
attaches a and b as parameters?

However, D cannot do something like this exactly, because expressions 
define the tuple, not how they are used.

But this is possible (with the proposed DIP or ours):

alias sql = "select * from blah where a=$a, b=$b"; // aliased to the tuple

connection.query(sql);
a = 5;
connection.query(sql); // another query with `a` set to 5 now.

Swift can do some pretty cool things due to the type resolver, but it 
comes at a cost (some expressions that are trivial in D make the 
compiler complain about them taking too long to resolve).

> I also didn't realize the takeaway would be that swift does appending 
> 😆- which by the way, is not completely accurate. And it does not 
> generate temporaries (unless you mean passing in parameters? There's no 
> way around that if you want to end up with a string based on runtime 
> values - it'll have to be processed in to a string somewhere).

For example, the part where they change the date formatting, they use a 
date formatter to generate a string for the date, which then is appended 
to the string interpolation.

Yes, you need to allocate a string. But you should only allocate one.

> You can also get an interpolated string directly in to "print 
> processing" if you wanted to: https://swift.godbolt.org/z/muAzgm

Hm... I'm not too impressed with this when compared to writefln(i"hello 
$("hello"), $x"); which works without such extra mechanics or strange 
call syntax.

> 
> When it comes to printing it really doesn't matter if you construct a 
> string on the stack and pass it along. You're IO bound anyway.

IO is not usually processed directly to the device. Usually it's 
buffered. Writing directly to the buffer is preferable to generating a 
string on the stack, and just copying that to the buffer.

> One very interesting thing of note is the way they combine named 
> arguments with string interpolations.

Yeah, that part is cool. But that comes for free with Swift. Potentially 
with the right additions to the named parameters DIP, it would be 
feasible to do something similar with this DIP.

> Also another note, this tuple expansion should really not be called 
> string interpolation, since it does not result in a string :/ It's more 
> string expansion really.

I recommended calling it a "formatted tuple" to avoid conflation with 
existing string interpolation implementations.

-Steve