new annotation or pragma to mark functions that are intended to be only used during compile time

[Ilya]

On Thursday, 13 February 2025 at 17:16:45 UTC, user1234 wrote:

>> ```cpp
>> int f(int x) @ctonly { return x + 1; }
>> enum a = map!f([1, 2, 3]).array;
>> ```
>
> This is not that a problem imo. I think @ctonly would only be 
> used in a certain
> way that is `mixin(someCall(someArgs))`, so if a few useless

Oh, no :) I've taken the `map` example from the real code, we are 
*very* creative in our CTFE usage :)

So, yes, we have functions we want to mark @ctonly that we use 
with `map` and other high-order functions. And with no inference 
that's not possible without changing the stdlib.

> code still slips in the object files, well that's a pity, but 
> that can get fixed later.

No, it's not about some code slipping (in my example, `map!f` 
code will still be generated I believe), but rather not being 
able to turn some functions into @ctonly at all.

Yes, we could use `staticMap` instead of `map`, but there are 
tradeoffs.

> Overall that's a good idea. In the bug tracker we have that 
> alternative that is "pure functions must be ctfe-able". Problem 
> is that D purity is not strong, you can wrap a function in a 
> delegate so that it appears to be pure to the compiler; so the 
> obvious question is "@ctonly would mean strongly-pure" ?

No, the obvious (even though stupid) example would be @ctonly 
function that is _never_ used: it can do anything it wants. 
@ctonly means only that the function is never needed at runtime, 
that's it.

You can continue saying that if it can't be used at runtime, when 
probably it has to be usable at compile time, so it has to be 
ctfe-able. And then if ctfe-able implies strongly-pure (which I'm 
not sure is true), you can conclude that @ctonly implies (under 
the assumption of being used) strongly pure.

But that's not my goal.

> Also as far as I understand the intent, it should be well 
> denoted that the goal is to skip emiting useless code in the 
> objects.

It's not so much about having this useless code in the objects, I 
think the linker does the good job with garbage collection 
usually. But I do care about the time spent in generation of this 
useless code which turned to be non-trivial. I think I wrote that 
in the Motivation section, but probably I could be more clear 
about that.