This was suggested before, but I’ll try to show another angle of this.

The if __ctfe construct

It would be a new syntactic construct different from if (__ctfe). We could also decide to special-case if (__ctfe), either way: The branch in which __ctfe is guaranteed to be true should be ignored w.r.t. some attribute checks: In a __ctfe section,

• a @nogc function can allocate, and
• a @safe function can do pointer arithmetic.
• maybe: a nothrow function can throw, except when control-flow reaches the throw expression, it halts for error.

Allocation at CTFE isn’t what @nogc is about and safety checks are done at CTFE anyways even for runtime-unsafe operations.

The function attribute __ctfe

• Add __ctfe as a function attribute.
• Overloading on __ctfe is possible and useful: Overload resolution for run-time code generation discards all __ctfe functions; overload resolution at CTFE prefers an overload if, after partial ordering, it is the only overload annotated __ctfe among the best matches.
• A __ctfe function admits no safety attributes or @nogc (make no sense).
• A __ctfe function is guaranteed not to be emitted into the binary.

On Tuesday, 29 July 2025 at 12:00:02 UTC, Quirin Schroll wrote:

Note that this is implemented in OpenD, it works fine and enables some interesting pattern when combined with a default parameter bug fix.

See:
https://dpldocs.info/this-week-in-d/Blog.Posted_2024_11_25.html#to-set-the-stage-for-new-memory-patterns

Same result can be achieved by the if(__ctfe) {} branch....

this is something opend tried to do via a pragma, but had to revert since our impl introduced regressions. some day we'll get back and finish it though.

On Tuesday, 29 July 2025 at 12:00:02 UTC, Quirin Schroll wrote:

I still think using a contract and treating it specially is the way to go since all we have to do is change the implementation:

string myStringMixin()
    in(__ctfe)
{

}