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

[Tejas]

On Friday, 14 January 2022 at 20:59:18 UTC, Timon Gehr wrote:
> On 1/14/22 19:32, H. S. Teoh wrote:
>> On Fri, Jan 14, 2022 at 07:24:22PM +0100, Timon Gehr via 
>> Digitalmars-d wrote:
>>> On 1/14/22 18:41, H. S. Teoh wrote:
>>>> But in D, whenever a variable is declared, it gets 
>>>> initialized to
>>>> its default value unless specified otherwise. Since nothing 
>>>> is
>>>> specified here, it ought to perform its default 
>>>> initialization, and
>>>> since there is no value with which it can be initialized, it 
>>>> ought
>>>> to raise a runtime exception.
>>>
>>> I don't follow why this is necessarily desirable. E.g., if 
>>> generic
>>> code checks whether or not a type can be default constructed, 
>>> it will
>>> by default get a spurious "yes" answer and has to special case
>>> `noreturn`.
>> 
>> ? Isn't that exactly what it should be?  If generic code 
>> checks whether
>> type T can be default constructed, and T happens to be 
>> noreturn, then it
>> would fail because noreturn.init is not constructible.
>
> noreturn.init is assert(0), which compiles.
>
>> Presumably, the
>> code is doing this check because it's about to create a 
>> variable of type
>> T afterwards, so returning "yes" would lead to instantiating 
>> noreturn
>> variables. Why would that be a good thing?
>> 
>> 
>> T
>> 
>
> My point was the opposite of what you now seem to be taking it 
> to be. You said there ought to be default initialization, which 
> for noreturn is a runtime exception. I asked why this "ought" 
> to be so.

Not to put words in HS's mouth, but I think the reason why simply 
declaring the `noreturn` variable should lead to initialisation 
is because that's how _all_ variable declarations in D behave, 
unless you disable default initialisation, at which point it's a 
compiler error to simply declare the variable.

`noreturn` not default initializing is therefore a special case, 
which I feel is undesirable