Quirin F. Schroll

You probably should include an *Alternatives* section to go into the details why the following pattern has too much drawbacks. That pattern isn't obvious because one wouldn't expect to be...

@MoonlightSentinel, true, but when else would you put the version?

The DIP does not (explicitly) talk about function pointer and delegate types, especially when those types are used as a function parameter or function return type. With this DIP, which...

@ntrel, in which regard would `@safe module foo;` be different from `module foo; @safe:`?

@ntrel, I used templates and attributes a lot, but never stumbled on this; wow. Probably because I consider `attribute:` harmful for anything except `public` and `private`.

I'm not sure if that DIP is the right direction. The `void` type is weird and has many quirks. Solving some of them can make matters worse, since people will...

As I see it, the only and best way out of the `void` oddities is dropping it altogether (except `= void` maybe) in D version 3.

About the *Prior Work* section: Isn't [C++'s consteval](https://en.cppreference.com/w/cpp/language/consteval) exactly what Don Clungston suggested `__ctfe` as a function attribute to do?

@PetarKirov wrote: > I think the best solution would be to use regular functions, but for the language to recognize a pattern like assert(__ctfe); and disable code generation for functions...

I had a similar idea. Your DIP proposes a pure addition to the language which avoids breakage. My approach contains breakage (in theory), but immediately works for all templates that...