Request for Comment assert(__ctfe)

[Dennis]

On Wednesday, 8 April 2020 at 09:48:25 UTC, Stefan Koch wrote:
> The only reason why I used assert (__ctfe) not static assert 
> (__ctfe) is because that's impossible to express.
> since __ctfe is a magic runtime variable that's hardwired to be 
> zero in the non-ctfe case.

Indeed, and that should make you think how you can properly 
express that instead of adding special cases to established 
language concepts making them mean an entirely different thing.

Imagine if D could not express quick sort, so programmers just 
use bubble sort instead out of necessity. Then to fix that, you 
let the compiler detect a common bubble-sort implementation, and 
replace it with a quick-sort implementation.

It is backwards-compatible and automatically works with existing 
code. What a fix!

Except even the slightest deviation of that pattern will break 
the optimization.
Also the quick-sort implementation is not stable unlike bubble 
sort, so the behavior is actually different making this an 
illegal optimization. What a hack!

Problems like this should be attacked at the root. This 
assert(__ctfe) hack may fix one thing in the short-term, but you 
gain a lot of technical debt. Next thing you'll stumble upon this:

```
import core.stdc.stdlib;
int* newIntPtr() @nogc {
     if (__ctfe) {
         return new int(); // Error: cannot use new in @nogc 
function
     } else {
         return cast(int*) malloc(4);
     }
}
```

What now, another hack? Or should we finally think of something 
to make __ctfe work with `static if` / `static assert` proper?