Compile Time vs Run Time

[Steven Schveighoffer]

On Friday, 12 January 2024 at 06:06:52 UTC, Walter Bright wrote:
> On 1/9/2024 3:49 PM, Paolo Invernizzi wrote:
>> 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.

The point is to pass the things that the compiler knows to the 
library, namely the string literal parts. Within the current 
domain of the D language, the best way to do this is to use 
string template parameters.

Necessarily, this is going to incur template symbol name 
explosion. I would love to solve this problem, especially in the 
cases where compile-time usage isn't needed. Having the 
compile-time expressions is essential when you need it, but is 
pretty ugly when you don't.

Again, we can have wrapper templates that do this for you. The 
problem (as always) is that these wrapper templates are still in 
there, still taking up space. Is there any room for a solution 
here? I'm talking about the compiler being clued in that these 
functions shouldn't exist in the binary. Then the compiler can 
take a lot of shortcuts (like hashing the type data instead of 
making a demangleable symbol).

But Timon is also right that the "format string" version is 
actually adding to the grief for library writers and users. 
There's no reason I can think of to add additional parsing 
requirements for the library. I'd prefer Jonathan Marler's 
solution of just interspersing strings and values if I had to 
pick between that and DIP1027. But that still leaves so much on 
the table of what *could be great*.

I also think it's fine to tell users 'Hey, you want formatted 
output? it's writef("format", args)'. My target was not and never 
will be, `writef`.

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

It actually is simple. It's a simple transformation from a parsed 
expression to the subexpressions contained within (sprinkling in 
types to make it easy to know what is what). What you *do* with 
the transformation might not be simple, but that's not necessary 
to use the feature.

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

I just looked it up and... no. It's not even close. There is no 
*requirement* to make this complicated. The transformation is 
simple and straightforward. It's easy to understand if you take 5 
minutes to read the docs.

If you want to build some insanely complex thing out of this, 
it's possible. But there is no requirement to use it that way. To 
reiterate, the *feature* is simple, what you can do with the 
feature is unbounded.

This is like saying templates are too complicated because of what 
you *can do* with templates.

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

I rest my case ;)

-Steve