"I told you so": noreturn sucks a leech and has virtually no utility

[Paul Backus]

On Friday, 15 October 2021 at 19:10:42 UTC, Stefan Koch wrote:
> On Friday, 15 October 2021 at 18:59:55 UTC, Timon Gehr wrote:
>> On 10/15/21 8:52 PM, Basile B. wrote:
>>> 
>>> No, you can use it everywhere a Type can be used: cast to 
>>> type, TemplateTypeParameter, VarDeclaration type, etc. And 
>>> most of the time this is obviously not useful and has to be 
>>> rejected, i.e during the semantic, i.e by the front-end.
>>
>> I don't think rejecting everything that's "obviously not 
>> useful" is the right approach. It just causes headaches for 
>> generic code.
>
> Seconded. The point of noreturn is precisely to reject less.
> The no-return type has no values which means reading or writing 
> that type is merely undefined behavior. It doesn't have to be 
> rejected.

It *shouldn't* be undefined behavior. What `noreturn` means is, 
"evaluation of this expression does not terminate normally". Some 
examples of `noreturn` expressions include:

- `assert(0)`
- `throw new Exception("error")`
- `{ while (1) {} }()`

The meaning of any *specific* `noreturn` expression is determined 
by the semantic rules given for that expression in the language 
spec--i.e., it is done on a case-by-case basis.

In the case of accessing a `noreturn` variable, the relevant 
semantic rule is given [in DIP 1034][1]: evaluating an expression 
that reads or writes a variable of type `noreturn` has the same 
behavior as evaluating the expression `assert(0)`.

[1]: 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1034.md#interaction-with-other-language-features