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