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

On Thursday, 9 April 2020 at 09:30:14 UTC, Timon Gehr wrote:
> On 08.04.20 12:27, Dennis wrote:
>> What now, another hack? Or should we finally think of something to make __ctfe work with `static if` / `static assert` proper?
>
> It's obvious how to make that work, but is it really worth the effort and compile time overhead? You'd have to perform semantic analysis twice for each function.

That could be a good POC implementation to start with, from there we can see how far it can be optimized.

However, what I meant with that statement was not that we literally should support `static if (__ctfe)`, just some way of actually statically recognizing ctfe-only code.

pragma(ctfe) looks like a promising candidate to me: https://github.com/dlang/dmd/pull/11014

On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> Hi Guys,
>
> [...]
>
> What do you guys think?
>
> Cheers,
>
> Stefan

Other and new thought.

This will have a positive impact on coverage maybe ?

I opened this a while ago: https://issues.dlang.org/show_bug.cgi?id=15590

(0 coverage should be ignored in __ctfe branches)

The problem would be partially solved when splitting the function in two versions.

On Thursday, 9 April 2020 at 10:14:21 UTC, Basile B. wrote:
> On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> [...]
>>
>> What do you guys think?
>>
>> Cheers,
>>
>> Stefan
>
> Other and new thought.
>
> This will have a positive impact on coverage maybe ?
>
> I opened this a while ago: https://issues.dlang.org/show_bug.cgi?id=15590
>
> (0 coverage should be ignored in __ctfe branches)
>
> The problem would be partially solved when splitting the function in two versions.

well ... splitting the function in two versions comes with the oblivious overhead of having to run semantic two times.
As well as having to maintain that in a multi-pass compilation model which we have to avoid having headers and that gives use the power to declare anywhere.