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

[aliak]

On Saturday, 29 February 2020 at 14:41:16 UTC, Steven 
Schveighoffer wrote:
> 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?

I'm not sure if it's in the video (I haven't seen the video). But 
it was just an example, implementations would vary I'd assume. 
Here's one from a quick search for e.g.: 
https://github.com/groue/GRDB.swift/blob/4c8574aa4c08ff715ce0e63b38502ac1e8529069/GRDB/Core/SQLInterpolation.swift

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

Yep, and similarly expressions define the interpolation pattern 
in swift, not how they are used as well. So the tuple thing is 
also pretty sweet! I'd imaging you'd be able to do something like:

auto sql = SQLStatment(i"select * from blah where a=$a, b=$b");

where

struct SQLStatement {
   string formatted;
   // What template magic is needed here? This is where I get a 
little worried.
   this(S : _interpolated_object!Specs, Specs, Args...)(S s, Args 
args) {
     // build formatted...?
   }
   alias formatter this;
}

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

Yeah, and that's pretty sweet too!

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

Yeah, swift ha a few problems with its type solver during 
semantic I think.

let a: Double = -(1 + 2) + -(3 + 4) + -(5)

Will fail to compile on my machine, and you need to break it up.

But, on the other hand, swift's constraint solver avoids 
backwards situations like:

void f(bool) { "bool".writeln; }
void f(int) { "int".writeln; }
enum A { one }
void main() {
     f(0);
     f(A.one);
}

And:

void main() {
     struct B {
         B opBinary(string op : "+")(int b) { return this; }
     }
     static if (is(typeof(B.init + size_t.init))) {
         size_t x = 1;
         B b1, b2;
         b1 = b2 + x; // fails here
     }
}


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

Generating temporaries is not a constraint that the interpolation 
system puts on you.

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

Indeed.