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

[aliak]

On Friday, 28 February 2020 at 19:16:08 UTC, Steven Schveighoffer 
wrote:
> On 2/28/20 5:17 AM, Jacob Carlborg wrote:
>> On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright 
>> wrote:
>> 
>>> I don't know Swift, but this looks like the "generate strings 
>>> and concatenate them" approach.
>> 
>> No, it basically lowers to bunch of method calls. Here's an 
>> example of how it could look like with D syntax:
>> 
>> auto a = 3;
>> auto b = i"foo $a bar";
>> 
>> Could be lowered to:
>> 
>> auto _temp = StringInterpolation(8 /* literal capacity */, 1 
>> /* interpolation count */);
>> _temp.appendLiteral("foo ");
>> _temp.appendInterpolation(a);
>> _temp.appendLiteral(" bar");
>> auto b = _temp.toString();
>
> I think Walter's point is that swift is still appending strings 
> and then returning that. This requires allocations, and is not 
> as preferable as directly processing the data. Not only that, 
> but it's generating temporary strings just to add them to the 
> larger thing that will be printed (I'm assuming this is not 
> just a big string but an array/list, due to the beginning of 
> the video and s1+s2+s3+s4).
>
> I'd much prefer for example, printing using DIP1027 than 
> constructing a string (even if the memory is reasonably fast, 
> like malloc) just to throw it away.
>
> I watched a lot of that video, it didn't impress me much. I use 
> swift interpolation strings quite a bit, and they are useful. 
> But I think D's will be much more performant and more 
> straightforward for hooking (if they ever get in).
>
> -Steve

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 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).

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

And for the record I think the tuple generation is great as well. 
I highly doubt it'll be easier to use than swift (case in point: 
no need to call idup or whatever to convert to a string, since a 
string in swift is a type that is "interpolation aware"). Hook in 
to maybe, it depends on the APIs provided to hook in to them. An 
opaque type will not be easier to hook in to and a "concrete" 
named interface (aka protocol in swift).

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.

By the by: if you or anyone is interested in swift's string 
interpolation design decisions (for inspiration or whatever) then 
here's the full discussion: 
https://forums.swift.org/t/string-interpolation-revamp-design-decisions/12624

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

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.