Tuples, CTFE, and Sliding Template Arguments

[Timon Gehr]

On 1/15/24 02:27, Walter Bright wrote:
> I'll summarize up front, and so one can skip the detailed reply below. 
> It's obvious there's no meeting of the minds here. I'll just explain 
> where I'm coming from.
> ...

Well, it is sad that you feel this way.

> Features doing simple things should be simple. That's the case with 
> 1027.

It's not the case. Format strings are not simpler, you even got it 
wrong. In fact, you got it wrong in the DIP1027 specification, in the 
DIP1027 implementation and now in the format string parser within the 
`execi` example.

> 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).

That's DIP1036e, not DIP1036. DIP1036 does not have templates separating 
the arguments, it only has a header at the start.

> 
> It's fine that transmorgrifying the string to adapt it to SQL has complexities to it. That's expected. If that's all string interpolation would be used for, that's ok.
> ...

DIP1027 is not simpler.

> But people want to use string interpolation for mixins, etc., all that have nothing to do with SQL. The transmorgrification should not be necessary for those cases, it should just work.

It does not with DIP1027, you still need to call some function, same as 
with DIP1036e, and that function itself will be more complex and harder 
to get right. (Though that really hardly matters as the functions needed 
for simple use cases are in Phobos anyway.)

> But it doesn't, if the filter isn't applied there's a significant runtime and code space cost.
> ...

DIP1036e can be slightly inefficient by default.
DIP1027 is unsafe by default. Companies went out of business due to a 
SQL injection attack. People's private information got leaked.

I really do not understand why instead of using DIP1036e as a sane 
starting point and addressing the issues with efficiency, you use 
DIP1027 as a starting point make it only slightly safer, relying on the 
library author to get things right in terms of safety, while nudging 
them into the direction of doing it unsafely. D has a long track record 
of encouraging safer patterns, and this should not be an exception.

> 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.
> ...

That is not true.

> That's the extent of my unease with it.
> ...

Well, then I think you should be able to see it my way, by recognizing 
that format strings are not actually simpler.

> Does 1027 do *everything* 1036 does? No. There's the Format can be implicitly converted to a string thing.

I am amazed this is still the only drawback that comes to your mind.

> So there's a tradeoff. Do we trade off a minor thing for a fair amount of complexity that yes, the user will see? Every feature in D is a compromise of one sort or another. I fall on one side of that, you the other.
> ...

I think not having istrings at all is significantly better than having 
DIP1027.