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