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

[Ilya]

On Sunday, 23 February 2025 at 17:57:58 UTC, Hipreme wrote:
>> I honestly prefer a linker error over a run-time assert :) 
>> Sounds like a time bomb.
>
> There are people out there which can't read linker errors, 
> contrary to that, I believe that an advanced feature anyway. To

Yes! Absolutely! That's exactly my point. I even believe that if 
one is using a modern programming language and is not doing 
something very hacky or low-level, there should not be any linker 
errors at all. That's why I'm pushing for a compile-time check 
here. Clear compilation error is **much** better than obscure 
link error. I would never argue that.

But in the quoted sentence I'm talking about linker error vs 
run-time assert in release build. And I would totally pick a 
linker error over that even if I couldn't read link errors. Even 
if cryptic, that's still a build time error, one can bisect the 
changes even without understanding it, find the culprit and 
either fix or revert. Compare that to hitting an assert in 
release mode in production three days after deployment.

> be fair, nowadays, I understand them enough for that. Maybe we 
> could implement that behavior of no-codegen vs a stub with 
> assert(false) with the same strategy as `-check=`.

We can certainly gate the new functionality behind a flag... But 
TBH I don't see much value in it. There is literally no existing 
code with `@__ctfe`, and it can't really work with 
`assert(__ctfe)` anyway.

> Since assert(`__ctfe`) is existing code, I would say that, 
> implementations that skip codegen because of `assert(__ctfe)`, 
> we could instead, we could do like `-ctfeskip=stub` and 
> `-ctfeskip=yes` or something like that.

Well, with `assert(__ctfe)` `-ctfeskip=yes` could lead to link 
errors. And `-ctfeskip=stub` is changing existing behavior.

> While `@__ctfe` would altogether trigger the same behavior as 
> no codegen at all, like `-ctfeskip=yes`.

Ok, that's fine. But we either need a compile time check, or 
there will be link errors.

> That would bring:
> 1. More control to one which understand what they're doing by 
> using either `@__ctfe` and `-ctfeskip=yes`.

I suggest we just pick that. More control for those who opt in.

> 2. Benefits existing code
> 3. Avoid breaking existing code since the default could be 
> using the stub.

But stubs **do** break existing code. I've already posted a 
scenario. Now if you don't hit `assert(__ctfe)` with debug 
executable, in release it will happily execute the function in 
run time. With stubs it will break.