On Saturday, 13 January 2024 at 06:27:51 UTC, Walter Bright wrote:

I don't see people arguing that escaping is difficult to do. It's not. What is difficult is remembering to do it perfectly, every time, and accidentally building a silent injection attack when you (inevitably) fail. Especially since the attack vector is not detectable to linting tools. All systems with a special format-specifier are unsafe for use with SQL. Period.

Think of it this way: You have the option to install a fail-safe critical system in your jet, and everybody is telling you do it, but you're saying "Nah fam, it'll be fine. The odds are so low that a human will screw up this one manual step and this design will burn 0.1% less fuel and costs 10% less." coughMCAScough.

Actually, MCAS is a pretty fair analogy here. The system mostly works as designed, except for the one button that if you don't push it when things go bad, brings down two airframes. That's how big a deal SQL injections are.

Don't be 2010's Boeing, be 1970s Boeing. Please build an indestructible 757.

Note that Java considered and rejected your premise in their version of this feature, with their reasoning laid out in the spec-document.

On Saturday, 13 January 2024 at 07:03:14 UTC, Adam Wilson wrote:

Looks like it's already a feature: https://www.baeldung.com/java-21-string-templates

Thanks, I wasn't aware of this.

On Friday, 12 January 2024 at 22:35:54 UTC, Walter Bright wrote:

I agree, good idea, but it can be even more generalized, please check Rikkis idea.
https://gist.github.com/rikkimax/812de12e600a070fe267f3bdc1bb3928

Or distilled to a few lines by me...

alias I(T...) = T;

void pluto(int a)
{
    pragma(msg, __traits(getArgumentAttributes, a));
}

void main()
{
    pluto(@"%s" I!1);
}

On Saturday, 13 January 2024 at 06:46:54 UTC, Walter Bright wrote:

No it is just as simple. I agree that the user should have to understand the feature before hooking it. I meant it is intentional that you can't "accidentally" hook istring calls without understanding what you are doing.

And I don't understand this line of argument to begin with. You have to be pretty familiar with D to hook anything:

• operator overloads
• foreach
• toString
• put
• DIP1027
• DIP1036e
• this thing you are proposing

And I'm sure there's more.

This doesn't help, as an enum implicitly converts to its base type.

In none of the proposals I have written or supported, has it been meant for writef. I don't understand the desire to hook writef and format. The feature to make 1036e hook writeln is just an easy added thing (just add a toString and it works), but is not fundamentally necessary. We could just as easily change writeln to handle whatever template types we create.

Hooking writef involves adding semantic requirements on the library author that are specialized for writef, for what benefit, I can't really say. You can always create a writef overload that handles these things, but I don't see the point of it. String interpolation isn't aimed at formatting, though it can be used for it (as demonstrated).

Me too. But shouldn't we prefer compiler errors? Shouldn't we use the type system for what it is intended?

I've literally left bugs like this in code for years without noticing until the actual thing (an exception) was printed, and then it was hours to figure out what was happening.

This would be a step up, but still doesn't fix the format specifier problem.

Right, but this doesn't fix the format specifier problem. You seem to be solving all the problems but that one.

Without a trailer, this isn't solvable technically. But I'm not really concerned about nested istrings. I just meant that it isn't a requirement to disallow them somehow.

The compiler is required to parse out the parameters. It has, sitting in it's memory, the list of literals. Why would it reconstruct a string, with an arbitrarily decided placeholder, that you then have to deal with at runtime or CTFE? You are adding unnecessary work for the user, for the benefit of hooking writef -- a function we control and can change to do whatever we want.

The SQL example DOES NOT generate a format string, I've told you this multiple times. It generates a string with placeholders. There is no formatting. In fact, the C function doesn't even accept the parameters, those happen later after you generate the prepared statement.

But also, SQL requires you do it this way. And the C libraries being used require construction of a string (because that's the API C has). An sql library such as mysql-native, which is fully written in D, would not require building a string (and I intend to do this if string interpolation ever happens).

Things other than SQL do not require building a string.

Yeah, I've never cared about hooking writef, it's fine as-is (well, it's fine if that's what you like). The fact that you have to put in %s everywhere, it's a klunky mechanism for "output this thing to a character stream".

Can't tell you how many times I've written a toString hook that calls outputRange.formattedWrite("%s", thing);. That "%s" is so ugly and useless. But this is all D gives me to use, so I use it.

Wait, so generating an extra template is a bridge too far, but parsing a DSL at compile time is a rounding error?

In my testing, CTFE concatenation is twice as fast as parsing, and uses 1/3 less memory.

Not to mention that concatenation is easy. I can do it in one line (if I don't really care about performance). The same cannot be said for parsing.

So I'd say, the user must understand that he's receiving a template, but also does not have to learn how to properly parse a specialized unrelated DSL. Format strings are weird, confusing, klunky, and less efficient.

If the template-parameter version is less preferred, it will only be used with an explicit template parameter.

It's not a problem, it just is one more quirk that is surprising.

-Steve

On Saturday, 13 January 2024 at 13:14:28 UTC, Nick Treleaven wrote:

I like this one, the only thing to think about is what to do with existing calls like:

format!"%s"("hello");

What goes where? Does "hello" get pushed to the args, or is it still the format string? Does it just not match that overload, and now you need separate overloads for when you explicitly instantiate with a parameter?

-Steve

On Friday, 12 January 2024 at 22:35:54 UTC, Walter Bright wrote:

But notice that `args` are runtime arguments. It turns out there is no way
to use tuples to split an argument tuple into compile time and runtime tuples:

What if you split the type-tuple instead but store a value at [0].

import std.stdio;

// Works today!
void pluto_v1(Args...)(string, Args[1] a1, Args[2] a2)
{
    pragma(msg, Args[0]); // Compile-time value!
}

// Almost compiles... add 'void' to explicitly slide instead of implicit magic.
void pluto_v2(Args...)(void, Args[1..$] args)
{
    pragma(msg, Args[0]); // Compile-time value!
    args.writeln;
}

void main()
{
    pluto_v1!("x", int, int)("x", 2, 3);
//  pluto_v2("x", 2, 3);
}