Tuples, CTFE, and Sliding Template Arguments

[Richard (Rikki) Andrew Cattermole]

On 15/01/2024 2:27 PM, 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.
> 
> 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).
> 
> 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.
> 
> 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. But it doesn't, if the 
> filter isn't applied there's a significant runtime and code space cost.
> 
> 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.

As others have said, 1027 is not simple. In fact it is the sort of 
feature when used will be considered a program security risk that 
companies will forbid the use of. A little bit of bad syntax sugar is 
not worth losing money over and it will happen, the question is when not if.

It requires an extensive infrastructure to process, and even then you 
are unlikely to get it right. As a feature it is a net negative. Almost 
every person who has had an opinion on such a feature has expressed 
dislike and out right thinking it is problematic. It cannot go in.

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

I on the other hand quite like it.

> On 1/13/2024 9:12 AM, Steven Schveighoffer wrote:
>> This doesn't help, as an enum implicitly converts to its base type.
> 
> It's a point for 1036.
> 
> 
>> 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`.
> 
> A format string is needed to support formats like "%03d". I understand 
> that is not needed for SQL, but support for formats is not so 
> straightforward with 1036.

It is also not straight forward for 1027 either.

People are moving away from percentage escape formats. They are variable 
length and therefore cannot be parsed generically.

Whereas f-string's which is what everyone is moving towards are 
incredibly easy to parse for their format. I have mine working with both 
formatting and date/time (which has its format based upon PHP's 
percentage escape yuck).

Overall I'm happy with it.

>> Me too. But shouldn't we prefer compiler errors? Shouldn't we use the 
>> type system for what it is intended?
> 
> We should prefer compiler errors, I agree. But everything has a cost to it.

Yeah turn around time.

Sure compilation might be slower by a few millisecond, but hey lets use 
more of the developer time which is far more constly and could cost 
hours instead!


Realistically though, have you reviewed my proposal for call site UDA's?

In a very short space of time, while I was tired I was able to mock up 
getopt without any additional templates.

Later on whilst tired and not thinking straight I was asked to 
demonstrate how SQL with string interpolation could work. I wrote the 
few lines to do that succinctly in a matter of a couple of minutes.

I don't understand the problem here. We have a solution that appears to 
tick the design requirements you have expressed and you have not so far 
reviewed it. Please do.