Tuples, CTFE, and Sliding Template Arguments

[Timon Gehr]

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!