Tuples, CTFE, and Sliding Template Arguments

[Walter Bright]

On 1/12/2024 8:35 PM, Steven Schveighoffer wrote:
> On Saturday, 13 January 2024 at 02:16:06 UTC, Walter Bright wrote:
>> On 1/12/2024 4:15 PM, Steven Schveighoffer wrote:
>>> I don't view this as simpler than DIP1036e or DIP1027 -- a simple 
>>> transformation is a simple transformation.
>>
>> Adding extra hidden templates isn't that simple. If a user is not using a 
>> canned version, he'd have to be pretty familiar with D to be able to write his 
>> own handler.
> 
> Yes, that is intentional.

So you agree it is not simpler :-)

> You should not be able to call functions with new 
> syntax because the parameters happen to match. We have a type system for a reason.

I proposed in the other topic to type the format string as Format (or 
FormatString), which resolves that issue, as a string is not implicitly 
convertible to a FormatString.


>> 1027 is simpler in that if the generated tuple is examined, it matches just 
>> what one would have written using a format. Nothing much to learn there.
> 
> In other words: "it matches just what one wouldn't have written, unless one is 
> calling `writef`".

Yes, it is meant for writef, not writeln.


>> The other reasons:
>>
>> 1. preventing calls to functions passing an ordinary string as opposed to an 
>> istring tuple
> 
> I don't see how this proposal fixes that. I'm assuming a function like `void 
> foo(string s, int x)` will match `foo(i"something: $(1)")`

Yes, we've seen that example. It's a bit contrived. I've sent a format string to 
a function unexpectedly now and then. The result is the format string gets 
printed. I see it, I fix it. I can't see how it would be some disastrous 
problem. If it indeed a super problem, `Format` can be made to be a type that is 
not implicitly convertible to a string, but can have a string extracted from it 
with CTFE.

What it does fix is your other concern about sending a string to a function 
(like execi()) that expects a Format as its first argument.


>> 2. preventing nested istrings
> 
> Why do we want to prevent nested istrings? That's not a goal.

I mentioned in another reply to you a simple solution.


>> have already been addressed. The compile time thing was the only one left.
> 
> A compile time format string still needs parsing. Why would we want to throw 
> away all the work the compiler already did?

For the same reason writefln() exists in std.stdio, and people use it instead of 
writeln(). Also, the SQL example generates a format string.


> If you want to call `writef`, you can construct a format string easily at 
> compile time. Or just... call `writef` the normal way.

??

> Compile-time string parsing is way more costly than compile-time string 
> concatenation.

I suspect you routinely use CTFE for far, far more complex tasks. This is a 
rounding error.


> Ok. This does mean, for *intentional* overloading of a function to accept a 
> compile-time first parameter, you will have to rename the function.

You can overload it with existing functions, or give it a new name. Your choice, 
I don't see problem.