Tuples, CTFE, and Sliding Template Arguments

[Nickolay Bukreyev]

On Sunday, 14 January 2024 at 02:49:24 UTC, Jonathan M Davis 
wrote:
> And I'd really rather not have runtime arguments silently 
> become compile-time arguments base on how a function signature 
> is written (which could change when the code is refactored).

Agreed.

Let me tell you a story. I once had to refactor a D codebase that 
exhibited monstrous memory usage during compile time. I quickly 
figured out the cause: it was instantiating tons of different 
templates with tons of different arguments, most notably value 
(i.e., non-type) arguments. Many of those template instantiations 
could be turned into CTFE computations, and some of those 
arguments could even become runtime arguments with little to no 
drawbacks.

So what I did was pretty straightforward: I went through the 
codebase looking for `!(...)` and considered whether I could move 
those template arguments to runtime (or CTFE, which is 
syntactically the same). If a snippet had no `!(...)`, I was 
confident it didn’t pass value arguments to templates and thus 
wasn’t related to the problem I was fighting.

If something like Sliding Template Arguments existed at that 
time, my task would be much harder. For a call `foo(arg)`, I 
would have to check whether `arg` was compile-time-known, and if 
so, look at the signature of `foo` to find out how it was 
receiving it. I would have to do that for _every_ argument of 
_every_ function call.

Now you probably understand why I’m not keen on the idea of 
magically turning what syntactically looks like a runtime 
argument into a template argument. I’d really prefer it [the 
other way 
around](https://forum.dlang.org/post/cfizhoqdmxrexupcwpmc@forum.dlang.org): if you need a separate instantiation per value (as opposed to type) of a parameter, put an exclamation point. `!(...)` is what turns DMD from one of the fastest compilers into the most memory-hungry one; I think it should remain explicit.