The state of string interpolation

Paul Backus snarwin at
Thu Dec 6 19:12:52 UTC 2018

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 
> 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 
     db.exec("SELECT * FROM foo WHERE id IN ($a,$b$c)");

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

More information about the Digitalmars-d mailing list