Request for Comment assert(__ctfe)
Dennis
dkorpel at gmail.com
Thu Apr 9 09:49:31 UTC 2020
On Wednesday, 8 April 2020 at 23:45:43 UTC, Jonathan M Davis
wrote:
> because it has enough information to do that optimization, and
> if assert(__ctfe) is used where it shouldn't be, then it will
> just result in an error when compiling/linking your program
> instead of at runtime.
It's not an optimization, it is a breaking change that can turn
valid code into compile errors or linker errors. Minimal examples
are:
```
int ctfeOnly() {
assert(__ctfe);
return 3;
}
int alsoCtfeOnly() {
version(all) {
assert(__ctfe); // ctfe detection is defeated by the
slightest deviation
return ctfeOnly();
}
}
```
This will become a compile error.
```
immutable ctfeOnly = function int() {
assert(__ctfe);
return 3;
};
```
This will become a linker error.
> It would arguably be cleaner if __ctfe were done in a way that
> it were a static condition rather than a runtime one (and thus
> static assert could be used instead), but that's not how it
> works, and from what I understand of how CTFE in general works,
> it's highly unlikely that that will ever change.
I don't agree there. First of all, this seems like an
implementation difficulty, not a fundamental limitation. Second
of all, there are plenty of alternatives to consider, such as
version(__ctfe) or pragma(ctfe). Johannes Pfau is working on the
latter right now: https://github.com/dlang/dmd/pull/11014
More information about the Digitalmars-d
mailing list