The state of string interpolation

[Steven Schveighoffer]

On 12/6/18 1:28 PM, Neia Neutuladh wrote:
> On Thu, 06 Dec 2018 18:06:51 +0000, Adam D. Ruppe wrote:
>> I would take it one step further and put the other stuff in a wrapped
>> type from the compiler, so the function receiving it can static if and
>> tell what it is, so
>>
>> i"foo $(foo)"
>> would be
>>
>> tuple("foo ", FromInterpolation("foo", foo))
> 
> I was about to suggest wrapping the non-parameters in a Literal{} struct,
> but FromInterpolation makes more sense.
> 
> I was thinking about protecting against errors produced when you have to
> use an even/odd rule to figure out what's part of the literal and what's
> part of the interpolation:

Hm... this is a good point. Two symbols back to back would be confusing 
if one was a string.

One possibility is to pass an empty string to separate them, but this is 
hackish.

Or you could check the TBA trait that says which parameters were 
interpolations and which ones were literals.

> With FromInterpolation, you'd be able to reliably come up with the correct
> SQL: "SELECT * FROM foo WHERE id IN (?, ??)". Which is invalid and would
> be rejected.

Right, but it also requires that the callee deal with the 
FromInterpolation type, no? Whereas just passing the tuple doesn't 
require current code changes.

I suppose FromInterpolation could alias itself to the actual value. That 
way, it lowers to the original proposal.

One thing I'd say is that FromInterpolation should take the string 
interpolation as a comiple-time item.

In other words, I'd say it should be FromInterpolation!"foo"(foo). But I 
still like the idea of getting the alias from the original source, you 
can do so much more that way (thinking of UDAs).

Actually, considering the generative capabilities of D, you could have a 
function that accepts the DB query as a compile-time interpolated 
string, and simply generate the query string and call to the underlying 
library.

So many possibilities...

-Steve