bottom type as parameter or local variable, does that make sense?

Paul Backus snarwin at gmail.com
Sat Jan 15 14:43:14 UTC 2022


On Saturday, 15 January 2022 at 09:52:00 UTC, Max Samukha wrote:
> On Saturday, 15 January 2022 at 00:54:03 UTC, Paul Backus wrote:
>> Why does this exception exist? Because for any type `T` other 
>> than `noreturn`, the expression `T.init` evaluates to a value 
>> of type `T`. However, the expression `noreturn.init` does not 
>> evaluate to a value of type `noreturn`--because, as previously 
>> stated, *there is no such thing as a value of type `noreturn`*.
>
> I understand the argument and counterarguments. I don't know 
> what is the right way. I err on the side of not introducing the 
> special case: every variable in D requires initialization, and 
> initialization of noreturn should fail because the initializer 
> halts. You argue that noreturn doesn't have a value, so we 
> don't even need to evaluate the initializer. Tight corner.

Making initialization of `noreturn` fail at runtime would require 
*two* special cases: first, the special case of `noreturn` having 
no values when every other type in D has at least one value; and 
second, the special case of `noreturn`'s default initializer not 
evaluating to a `noreturn` value when every other type's default 
initializer evaluates to a value of that type.

There is an argument to be made that we should never have 
accepted special case #1 in the first place (i.e., that the 
`noreturn` DIP should have been rejected). But given that we 
have, I think it is better to accept the consequences that follow 
from that decision, strange though they may seem, than to 
introduce even more special cases to try and paper over them.


More information about the Digitalmars-d mailing list