On 1/12/2024 11:03 PM, Adam Wilson wrote:
> On Saturday, 13 January 2024 at 06:27:51 UTC, Walter Bright wrote:
>>
>> Escaping % is not hard to do. It's ordinary.
>>
> 
> 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.

1027 can do that automatically, so it will work every time. I've written code that parsed a string and escaped the naughty bits many times.

> Note that Java considered and rejected your premise in their version of this feature, with their reasoning laid out in the [spec-document](https://openjdk.org/jeps/430).

It's a long document. I'm not sure what you see as my premise and what the Java doc is specific about.

As for what my premise is, CTFE code can be written to validate strings. This is not difficult to do. It's put in the execi() function. It happens for every string. Once the code is written, it will work on every user-supplied istring.

DIP1036e doesn't have any magic bean to validate strings. It also has to code up a validator. Coding up the validator is a task for both proposals, and they'd do the same thing.

Furthermore, if a string type was passed to execi() as the first argument, it would not compile, as 1027 would type it as a `FormatString`, not a `string`. So execi() would only work on the output of the string interpolator, not any random string.

On Monday, 15 January 2024 at 01:27:00 UTC, Walter Bright wrote:

>> 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.
>
> When I've had an exception printed, I'll grep the code base for the message to see where it came from. The message should also say what was wrong. If it's a generic exception, I'll use the debugger to find where it came from. I doubt a format string error would be hard to track down, as it's only one level below the cause of the error.

That's not an option when working with relational databases, as their primary use is having multiple applications / tools / batch / maintenance people working on them concurrently.

Doing something wrong, _in production_, on a sql database, like updating / deleting / inserting something wrongly, for an erroneous sql or _erroneous_ binding of a D variable to a SQL parameters can't simply be resolved firing up a debugger or halting a company and restore a backup.

/P

On Monday, 15 January 2024 at 01:27:00 UTC, Walter Bright wrote:
> Features doing simple things should be simple. That's the case with 1027. Doing complicated things should be expected to be more complicated to use. With 1036, it starts out at the other end. It's complicated, with complexity that one has to write additional code to make it simple again (the "filter out the unnecessary templates" thing we talked about).
[...]
> Simple things should be simple, complicated things should expect complexity. But 1036 has simple things being complicated. Doing SQL is about the same level of complexity for 1027 as 1036. For doing simple things, 1036 remains complicated, and 1027 gets simple.

This part of the post is an argument about *usage* complexity, so let's compare what 1027 and 1036 are like to use.

For DIP 1027:

* writef just works
* For anything else, you have to process a format string at runtime using string parsing.

For DIP 1036:

* writeln just works
* For anything else, you have to process an argument list at compile time using introspection.

In the "just works" case, both are equally easy to use.

What about the case where it doesn't "just work"? For DIP 1036, D has world-class introspection facilities built into the language and standard library. For DIP 1027, the facilities we have for string parsing are...regex, I guess? So I would say 1036 has an edge here.

> Another illustration of this idea. For algorithmic code, I
> invented opApply(). But after experience with it, I slowly grew
> to dislike it because I could never remember how it worked, and
> would have to reread the documentation on it. The
> implementation of it is also ugly, as it has to rewrite the
> code that surrounds it. Heaven help anyone who has to read the
> code gen output of that. I much prefer the later approach using
> lambdas. They're simple, easy to remember and use. There isn't
> much implementation for them; they grew naturally out of other
> features in the language.

This part is an argument about *implementation* complexity, so let's compare implementations.

DIP 1036's PR includes a lot more tests and documentation than DIP 1027's, so comparing the PRs in their entirety doesn't make sense. Instead, I'm going to focus on the specific modules in the DMD frontend where the "meat" of the implementation lives.

For DIP 1027 [1], we have

* +141 lines in dmd.expressionsem
* +11 lines in dmd.lexer
* +11 lines in dmd.tokens (discounting the unrelated comment)

...which totals to 163 lines.

For DIP 1036 [2], we have

* +78 lines in dmd.expressionsem
* +166 lines in dmd.lexer
* +33 lines in dmd.tokens

...which totals to 277 lines.

So, by this measure, DIP 1036 has a more complex implementation than DIP 1027. Although in absolute terms, neither is especially complex.

For comparison, if I apply the same methodology to DIP 1038 (@mustuse) [3], I count 260 lines (in the dsymbolsem, expressionsem, statementsem, and mustuse modules)--pretty close to DIP 1036. Perhaps I'm flattering myself, but I would consider @mustuse to be a feature with a fairly simple implementation.

[1] https://github.com/dlang/dmd/pull/15722/files
[2] https://github.com/dlang/dmd/pull/15715/files
[3] https://github.com/dlang/dmd/pull/13589/files

On 1/15/24 09:03, Walter Bright wrote:
> 
> Furthermore, if a string type was passed to execi() as the first argument, it would not compile, as 1027 would type it as a `FormatString`, not a `string`. So execi() would only work on the output of the string interpolator, not any random string.

Do you believe that if the documentation has the following examples:

```d
writefln("%s", x);
writefln(i"$x");
```

Then it is not inevitable that at some point, someone will write an implementation of `execi` with the signature `void execi(T...)(string, T)` ?

On 1/15/24 11:39, Dukc wrote:
> On Friday, 12 January 2024 at 22:35:54 UTC, Walter Bright wrote:
>>
>> Given the interest in CTFE of istrings, I have been thinking about making a general use case out of it instead of one specific to istrings.
>>
>>
>> Sliding Template Arguments
> 
> There actually is a [DIP coming](https://github.com/dlang/DIPs/pull/232) that accomplishes the same thing as proposed here. It's waiting for Mike to open the DIP pipeline again.

It's essentially a more detailed version of Steven's proposal, with more use cases.

On 1/15/24 08:50, Walter Bright wrote:
> On 1/13/2024 1:24 AM, Timon Gehr wrote:
>> It's not rewritten like that with DIP1027.
> 
> I know. Based on our discussions, several improvements need to be made to DIP1027. I'm basing my argument on what DIP1027 would be with those improvements.

But you have not really been giving the same consideration to DIP1036e. Why should we accept your moving of the goalposts on DIP1027 while you argue as if DIP1036e drawbacks cannot be overcome?

What is the fundamental difference between DIP1027 and DIP1036e? Your insistence on a format string? That `printf` can be called with an istring? What are the design constraints here?

> For example, changing the type of the format string from `string` to `Format`, doing proper escaping of %, handling tuple arguments, handling nested interpolations, etc.

Ok. But how do you handle tuple arguments and nested interpolations? It does not seem easy, especially if the format string parts should all be accessible at compile time.

> The draft implementation of it also lacks things like proper parsing of `(expression)`, which is straightforward to fix and not any fundamental flaw in the design.
> ...

Well, the DIP1036e implementation is viable as-is.

> I also am not criticizing things in DIP1036e that should be improved, as that is irrelevant to the fundamental issues discussed here.

So you are criticizing things in DIP1036e with the intention that they should not be improved?

> The current implementation/spec seems to be missing things like escaping stray ? that could appear in the string literals.
> ...

No, the implementation of the language feature is complete. It's just that the proof-of-concept usage example did not do some sorts of validation. And anyway, this only serves to further highlight the error-prone nature of approaches based on special characters in a string.

> I.e. we should both be discussing what the two proposals *could* be, rather than what they *are* with their feet of clay.

We can do that, but then I do not really see why there still has to be a debate framed around DIP1027 vs DIP1036e in the first place. Clearly both of them *could* be the other one. The possibilities are endless!