The state of string interpolation

Olivier FAURE couteaubleu at gmail.com
Mon Dec 10 13:48:58 UTC 2018


On Thursday, 6 December 2018 at 16:19:12 UTC, Steven 
Schveighoffer wrote:
> With the concept of lowering to a tuple, I'd love to use such a 
> thing for database queries.
>
> For instance:
>
> db.exec("UPDATE Foo SET a = ?, b = ?, c = ?, d = ? WHERE id = 
> ?", aval, bval, cval, dval, id);
>
> vs.
>
> db.exec(i"UPDATE Foo SET a = $aval, b = $bval, c = $cval, d = 
> $dval WHERE id = $id");

I really like that, but I'd add a caveat: this syntax makes it 
harder for db.exec to know which arguments you give it are 
trusted compile-time inputs, and which arguments are unsafe 
runtime inputs.

I'd argue for a second syntax to be added as well, fi"formatted 
string". So:

db.exec(fi"UPDATE Foo SET a = $aval, b = $bval, c = $cval, WHERE 
id = $id");

would lower to:

db.exec("UPDATE Foo SET a = %s, b = %s, c = %s, WHERE id = %s", 
aval, bval, cval, id);

That way, db.exec would be able to interpret its first argument 
as trusted input and everything else as unsafe.

That syntax might be redundant if a builtin FromInterpolation 
struct is created. The thing is, there have been arguments 
against using a builtin struct, and a db.exec method built for 
interpolation would be incompatible with regular use, so this:

db.exec("UPDATE Foo SET a = ",aval,", b = ",bval,", c = ",cval,", 
WHERE id = ",id);

would not work, which would have to be documented, etc.

On the other hand, a fi"some string with $var" syntax could 
leverage any already existing db.exec method with a "C format" 
first parameter (including actual C functions?), without forcing 
the library implementation to differentiate between normal 
arguments and FromInterpolation arguments.


More information about the Digitalmars-d mailing list