We are forking D

[Paolo Invernizzi]

On Sunday, 7 January 2024 at 09:04:16 UTC, Walter Bright wrote:
> On 1/6/2024 9:35 PM, H. S. Teoh wrote:
>> Noteworthy is the fact that the competing string interpolation 
>> proposals
>> are *not* immune to this sort of SQL injection attack, because 
>> premature
>> conversion of the i"" literal to string *would* result in a 
>> successful
>> injection.
>
> The same technique of having a template take the generated 
> tuple and modifying it as it sees fit works with DIP1027, too. 
> I posted an example here in the last debate about this.
>
> The tuple generated from the istring is passed to a template 
> that accepts tuples. The format string is the first element in 
> the tuples, and it is a string literal. The template reads the 
> format string character by character, generating a new format 
> string as it goes. It examines the format specifications, and 
> the type of the corresponding tuple argument, and adjusts the 
> output to the new format string as required.
>
> The template then returns the new tuple which consists of the 
> new format string followed by the arguments.
>
> It's true that in order for this to work,
>
> ```
> db.execi(i"INSERT INTO sample VALUES ($(id), $(name))");
> ```
> would need to be written as:
> ```
> db.execi(xxx!(i"INSERT INTO sample VALUES ($(id), $(name))"));
> ```
> where `xxx` is the thoroughly unimaginative name of the 
> transformer template.
>
> Is adding the template call an undue burden? Follow the call to 
> deb.execi() with:
>
> ```
> std.stdio.writeln(i"id = ($(id), name = $(name)");
> ```
> I haven't tried this myself, as I don't have sql on my machine, 
> but I expect the output to stdout would not be what one would 
> expect. I.e. The imported Interpolation functions will produce 
> what is right for sql, not writeln, which would be in error.
>
> Since you do have this setup, please give this line a try and 
> let us know what it prints.

In our codebase, we are binding of local variables to sql 
parameters with something like:

   mixin( BindParameters!actualQuery );

Also that way of doing it is not 'an undue burden'.

The whole point is, well, let's move on and simplify it!

DIP1036 could allow us to do that, with better library code and 
more encapsulation, your proposal simply can't do that without 
what you call 'more burden'.

Long story short: in our codebase, we will stick with mixins with 
your proposal merged, on the contrary, we will use DIP1036 
functionalities if merged.

/P