On Thursday, 9 December 2021 at 14:13:58 UTC, Ola Fosheim Grøstad wrote:

Just to clarify to avoid unnecessary discussion about what I wrote, as I might not have been specific enough:

I am not suggesting the implementation of builtin string interpolation, but custom literals with conversion functions. It should probably not be called string_interpolation, just convert or @convert.

This is different from string mixins as it would be more composable, overloadable, and with stronger typing and no mixin.

It should work for custom literals like 100.34ms as well as sql"SELECT …".

As such, you would integrate the "DSL" more with regular D-code than you do with string mixins.

Basically: try to find a generic solution for custom literals that allows the implementation of string-interpolation.

On Wednesday, 8 December 2021 at 22:10:32 UTC, Steven Schveighoffer wrote:

So the string interpolation is used to emulate something like embedded SQL (ESQL) with the exception that the (SQL) code is quoted. ESQL looks like this [1]:

   EXEC SQL INSERT INTO tablename VALUES (:variablename);

This is clearly favorable over embedded question marks plus argument lists.

I missed that part.

[...]

conn.exec("UPDATE organization SET loc_lat = ?, loc_lon = ? WHERE id = ?", loc_latitude, loc_longitude, id);

// compare to:
conn.exec(i"UPDATE organization SET loc_lat = $loc_latitude, loc_lon = $loc_longitude WHERE id = $id");

Final questions: What happens if the "i" in front of the string is accidentally lost? Compile-time oder runtime error?

How does the compiler/runtime know which type of interpolation to choose? I mean if you have

   conn.exec (i"UPDATE organization SET loc_lat = $loc_latitude...
   html.output (i"<input value=\"$value\" ...

how and where is decided to use the SQL interpolation in the first and the HTML escaping in the second line?

What is the return type of the interpolation?

Stefan

[1] https://en.wikipedia.org/wiki/ECPG#Using_host_variables

PS: The following code snippet is from the YAIDIP document:

   executeShell("wget " ~ url ~ " -O" ~ file ~ ".frag && mv " ~ file ~ ".frag " ~ file);

That should not have been written in the first place. This code is prone to shell injection and the only shell-specific functionality is that of the "&&". Long story short: I would have written it that way:

   execute(["wget", url, "-O", file ~ ".frag"]).status == 0
   &&
   execute(["mv", file ~ ".frag ", file]);

On Thursday, 9 December 2021 at 14:25:10 UTC, Steven Schveighoffer wrote:

Well, the DIP does not propose string building, it is basically string-splitting with a bit of mixin… (kinda)

Anyway, you could define constants for SELECT, FROM and WHERE and get even better syntax:

sql(SELECT, r[0], r[3], FROM, t[3], WHERE, c[6])

Then let sql escape-wrap the parameters.

Ok, but maybe you could write even better libraries if D added custom literals instead? :-)

True, I don't use string interpolation in JavaScript much either. I use it everywhere in Python. The details matters a lot for it to increase readability.

I just wish D would focus more on providing generic solutions than N narrow special cases. I think these special cases are pushed in because people in the forums are too impatient to wait for the emergence of a generic solution. Understandable, but not good for the compiler/language over time.

On 12/9/21 9:25 AM, WebFreak001 wrote:

This is exactly what the proposal is doing. But instead of using sql as a specialized prefix (you have to be careful with these, as adding arbitrary literal prefixes can mess up the grammar) it's just a parameter tuple, and you specify the function as normal.

i.e. this is practically identical to:

sql(i"SELECT x,y,z FROM $something WHERE $condition");

Or even:

i"SELECT x,y,z FROM $something WHERE $condition".sql;

-Steve

On 12/9/21 9:33 AM, kdevel wrote:

    EXEC SQL INSERT INTO tablename VALUES (:variablename);

Yes, this is the biggest point of the DIPs that have been introduced so far -- put the parameters in context.

It might be implied and not specifically spelled out (I don't know, I read the DIP a long time ago).

conn.exec("UPDATE organization SET loc_lat = ?, loc_lon = ? WHERE id = ?", loc_latitude, loc_longitude, id);

// compare to:
conn.exec(i"UPDATE organization SET loc_lat = $loc_latitude, loc_lon = $loc_longitude WHERE id = $id");

It depends. If conn.exec accepts a standard string, then it's a runtime error -- without the i, the string is just a string, which contains the literal data with $loc_latitude, etc. which the SQL server doesn't understand. This is similar to what happens when you do (as I often do): writeln("%s: %s", name, value);

If conn.exec only accepts interpolated literals, then it's a compile time error.

    conn.exec (i"UPDATE organization SET loc_lat = $loc_latitude...
    html.output (i"<input value=\"$value\" ...

That is the beauty of this proposal! The parameters are simply passed as-is into the function. If the function accepts them properly, it gets to decide how to handle it.

html.output can do whatever it wants differently than conn.exec.

There isn't one. The interpolation is not a function, it's a literal that expands into a parameter list.

    executeShell("wget " ~ url ~ " -O" ~ file ~ ".frag && mv " ~ file ~ ".frag " ~ file);

    execute(["wget", url, "-O", file ~ ".frag"]).status == 0
    &&
    execute(["mv", file ~ ".frag ", file]);

Yeah, it might not explicitly state that the original code is subject to injection, but the interpolated version has the potential to avoid it, whereas the original snippet has no chance.

-Steve

On Thursday, 9 December 2021 at 14:57:25 UTC, Steven Schveighoffer wrote:

(no)

On Thursday, 9 December 2021 at 14:57:25 UTC, Steven Schveighoffer wrote:

sql(i"SELECT x,y,z FROM $something WHERE $condition");

i"SELECT x,y,z FROM $something WHERE $condition".sql;

I think identifiers immediately followed by a string literal are unambiguous. Currently a syntax error, afterwards useful interpolation.

The i"" proposal allows to pass multiple arguments at once, and with that adds new cases to the compiler that a single literal can be multiple arguments. The identifier + string literal stays within bounds of existing behavior.

I think you would really really never want to pass these raw tuple values to any function other than to explicitly designed interpolated string handlers.

Given that assumption I think it's safe to say the i prefix is redundant, and you should just always need to use a handler function. The identifier + string literal syntax elegantly does this without redundant syntax, it's familiar to JS programmers and it doesn't allow passing more than the interpolated string to handler functions or functions with variadic arguments. (which is a good thing)

Samples:

sql(i"SELECT x,y,z FROM $something WHERE $condition")
text(i"hello $name")
mixin(i"class $name {}")

vs

i"SELECT x,y,z FROM $something WHERE $condition".sql
i"hello $name".text
mixin(i"class $name {}") // no equivalent

vs

sql"SELECT x,y,z FROM $something WHERE $condition"
text"hello $name"
mixin"class $name {}"

or have some kind of new function call punctuation:

sql$"SELECT x,y,z FROM $something WHERE $condition"
text$"hello $name"
mixin$"class $name {}"

and if you want to actually access the tuple for variadic template arguments (including the header) you could still do this:

AliasSeq"hello $name"

(or alias I = AliasSeq; and I"hello $name")

On Thursday, 9 December 2021 at 15:16:40 UTC, WebFreak001 wrote:

sql(i"SELECT x,y,z FROM $something WHERE $condition");

i"SELECT x,y,z FROM $something WHERE $condition".sql;

and I want to add, this is the super rare case:

foo(i"hello $name")

this is the much more common case:

foo(i"hello $name".text)
// or
foo(text(i"hello $name"))

I don't think the common case should always have this extra i prefix + needed function calling parentheses or ufcs dot. Just only writing text"hello $name" is shorter, easier to type, better to read.

On Thursday, 9 December 2021 at 15:16:40 UTC, WebFreak001 wrote:

AliasSeq"hello $name"

this should have been:

tuple"hello $name"
// or
alias I = tuple;
I"hello $name"