The state of string interpolation

[Paul Backus]

Marler's original proposal is simple, orthogonal, and elegant. It 
makes use of existing D features in natural ways, and is both 
easy to understand, and easy to use in simple cases without 
*needing* to understand it. I think adding additional machinery 
like FromInterpolation on top of it would be a mistake. If users 
want to opt in to that extra complexity, it can always be made 
available as a library.

On Thursday, 6 December 2018 at 18:28:09 UTC, Neia Neutuladh 
wrote:
> 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:
>
>     auto c = ");drop table foo;--";
>     // whoops, forgot a comma
>     db.exec("SELECT * FROM foo WHERE id IN ($a,$b$c)");
>       ->
>     db.prepare("SELECT * FROM foo WHERE id IN(?, ?);drop table 
> foo;--?")
>       .inject(a, b, ")");
>
> 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.

The actual solution here is to use the type system to distinguish 
between trusted and untrusted strings. E.g.,

     UnsafeString c = getUserInput(); // e.g., "); drop table 
foo;--"
     db.exec("SELECT * FROM foo WHERE id IN ($a,$b$c)");

...and `db.exec` knows to escape its arguments iff they're 
UnsafeStrings.