Compile Time vs Run Time

[Walter Bright]

On 1/9/2024 3:49 PM, Paolo Invernizzi wrote:
> You are underestimating what can be gained as value in catching SQL problems at 
> compile time instead of runtime. And, believe me, it's not a matter of mocking 
> the DB and relying on unittest and coverage.

Please expand on that. This is a very important topic. I want to know all the 
relevant facts.


> CTFE capability is needed.

I concur that compile time errors are better than runtime errors. But in this 
case, there's a continuing cost to have them, cost to other far more common use 
cases for istrings. The cost is in terms of complexity, about needing to filter 
out all the extra marker templates, about reducing its utility as a tuple 
generator with the unexpected extra elements, larger object files, much longer 
mangled names, and so on.

Want to know the source of my unease about it? Simple things should be simple. 
This isn't. The extra complexity is always there, even for the simple cases, and 
the simple cases are far and away the most common use cases.

Frankly, it reminds me of C++ template expressions, which caught the C++ world 
by storm for about 2 years, before it faded away into oblivion and nobody talks 
about them anymore. Fortunately for C++, template expressions could be ignored, 
as they were not a core language feature. But DIP1036 is a core language 
feature, a feature we would be stuck with forever. And I'll be the one who gets 
the heat for it.

The compile-time vs runtime issue is the only thing left standing where the 
advantage goes to DIP1036.

So it needs a very compelling case.

P.S. You can do template expressions in D, too!