[WIP RFC]making __ctfe usable in static if

[UplinkCoder]

Hi this change allows __ctfe to be used in static ifs and static asserts.
Giving the developer a way to ensure (at compile time) that certain code-paths are never or only used at ctfe.
This effectively undos #4084

[UplinkCoder]

Oops I just spotted a big mistake,,,
fixing.

[wilzbach]

@UplinkCoder could you please add a test case to prevent regression and ensure it works on all platforms?

[MetaLang]

Isn't this a language change that requires a change to the documentation as well? I don't believe that __ctfe currently works correctly in static contexts.

[UplinkCoder]

Before I write docs I'd like to know if the community and leadership are okay with this change.

[UplinkCoder]

@wilzbach took care of the tests.

[schveiguy]

IIRC, @donc thinks __ctfe must be runtime variable. I don't pretend to know any details of how it works or is supposed to. Just wanted to make sure Don sees the proposal.

[UplinkCoder]

@schveiguy
A good idea.
I believe there was a reason back in the day which does not apply anymore.

[UplinkCoder]

passing the tests depends on dlang/druntime#1638

[dnadlinger]

This change is fundamentally incorrect. CTFE does not create a separate version of runtime functions, it just happens to execute them at compile time. For static if (__ctfe) – or indeed any use of __ctfe as a compile-time constant – to make any sense, there would need to be two different copies of the function body for the "actual function" and its CTFE variant.

However, this is not the case. There is only one copy of the function, and what your change does is merely to expose what triggered full semantic analysis for the function body to be run. This is of course just leaking an implementation detail, and not at all what __ctfe is supposed to do. For example, you could call ctfeFun() from main() in your test case and it would compile just fine. Similarly, it would cause existing code to execute if (__ctfe) branches at runtime if the function had been used at CTFE in the module where it is emitted.

[andralex]

@klickverbot makes sense

[UplinkCoder]

@klickverbot
I will go for another solution then.
The only real utility of __ctfe as a literal is to ensure that ctfeOnly functions don't end up in the binary.
The same can archived with a flag on the FuncDeclaration.
Closing as this is not the right way

[dnadlinger]

The only real utility of __ctfe as a literal is to ensure that ctfeOnly functions don't end up in the binary.

Yep – while LDC can use aggressive link-time dead code elimination (LTO/--gc-sections), a pragma/… like that would make sense to clarify intent and save on compile times. See also: ldc-developers/ldc#1554