Request for Comment assert(__ctfe)

[Timon Gehr]

On 06.04.20 04:25, Stefan Koch wrote:
> On Monday, 6 April 2020 at 01:28:19 UTC, Timon Gehr wrote:
>>
>> I don't understand how you would implement it in a way where the above 
>> does not work. Have you tested it? I am literally rewriting 
>> `in(__ctfe)` to `in{ assert(__ctfe); }` in the parser:
>>
>> https://github.com/dlang/dmd/blob/master/src/dmd/parse.d#L5060
> 
> I see. Well in that case it'll work out of the box.
> Although it does make me shudder to change the Tree in the parser in 
> such a way.

For no reason at all. It's the appropriate place to expand simple 
short-hand notation, e.g., see template functions.

It's just good engineering. Let's consider the evidence:

What you expected to be the case:

- `in(expr)` is a special kind of construct in the AST, burdening the 
entire compiler code base from frontend to backend.
- `in{ assert(__ctfe); }` and `in(__ctfe)` have diverging behavior, a 
unfortunate development caused by butt pain.

What was actually the case:

- `in(expr)` is simple shorthand notation and is treated by the compiler 
precisely like `in{ assert(__ctfe); }`
- `in(__ctfe)` works precisely like `in{ assert(__ctfe); }` even after 
the latter has been special-cased.

You might want to recalibrate your guts. :P

> When was this merged?

Just when it should have been, right after the corresponding DIP was 
accepted.