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

[Steven Schveighoffer]

On Thursday, 20 February 2025 at 19:44:37 UTC, Steven 
Schveighoffer wrote:
> On Thursday, 20 February 2025 at 17:42:25 UTC, Ilya wrote:
>> On Thursday, 20 February 2025 at 15:50:33 UTC, Steven 
>> Schveighoffer wrote:
>>> This has been proposed before, and it doesn't require 
>>> language changes:
>>>
>>> ```d
>>> void foo() {
>>>    assert(__ctfe);
>>> }
>>> ```
>>
>> Yes, I've seen that. But did it go anywhere? I think on the 
>> thread I've found there are some discussions with no 
>> conclusion.
>
> It has not gone anywhere, but if we were to consider a language 
> change, I'd want to evaluate whether this is a better option, 
> since it's a de-facto standard.

Paul Backus pointed out on discord, there is a very large problem 
with this mechanism:

importing a file with a function that is not a template nor an 
auto function means the semantic is skipped for that function. 
This means it would be impossible to know that this function is 
ctfe-only. The only other solution there is to semantic every 
function, which basically negates any wins we get from not 
optimizing these functions.

So reading all the responses here, my impression is:

1. I think it's a necessary idea to have an attribute if we want 
this feature. I like using `@__ctfe` as this requires no new 
syntax, and actually already compiles (it just doesn't do the 
thing expected). What remains to be seen is if we can hook this 
properly. `@__ctfe` becomes `@(true)` currently. If not, then a 
new attribute is trivial to add to core.attributes.
2. If we are going to have a mechanism to flag that code 
generation should be avoided, it would be good to also do this 
for functions that begin with `assert(__ctfe)`. This at least 
helps with existing uses of that mechanism.
3. I don't agree with the compiler errors for all uses of 
ctfe-only functions at runtime. As you pointed out, this can be 
valid for cases. I don't think it's worth the headache, and I 
have learned in the past not to pre-optimize for rule following 
especially in generic code. Just let the thing happen as it would.
4. To that end, calling a known ctfe-only function should result 
in an appropriate `assert(false, "cannot call ctfe-only function 
blahblah at runtime")` when doing code generation instead of the 
call to a non-existent function that has a linker error.

-Steve