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

Paul Backus snarwin at gmail.com
Fri Oct 15 19:38:52 UTC 2021

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)`.


More information about the Digitalmars-d mailing list