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

[Max Samukha]

On Monday, 17 January 2022 at 16:11:03 UTC, Timon Gehr wrote:
> On 16.01.22 23:56, Max Samukha wrote:
>> On Saturday, 15 January 2022 at 18:35:02 UTC, Paul Backus 
>> wrote:
>>>
>>> Technically, a variable is a name associated with a block of 
>>> memory, which may or may not contain a value. In the case of 
>>> `noreturn`, the block of memory has size 0, and there are no 
>>> possible values it can contain.
>> 
>> Memory of size 0 contains a single value, which is the value 
>> of the unit type, 0-tuple, or whatever. Zero type is 
>> different. Timon, I am totally confused, could you clarify?
>> ...
>
> I share your confusion. A block of memory of size zero indeed 
> has a unique value, not zero values. I don't think there is any 
> principled way to arrive at a semantics where the program 
> survives an attempt to initialize a `noreturn` variable. Also, 
> note that typically, if a type `A*` is a subtype of a type 
> `B*`, then `A.sizeof>=B.sizeof`. `noreturn*` is a subtype of 
> any `T*`. Hence, `noreturn.sizeof` should be at least 
> `size_t.max` or even `∞`. Thus, `noreturn.sizeof == 0` is 
> already a special case with a pragmatic justification and using 
> it to attempt to justify any further behavior of `noreturn` is 
> questionable in the first place.
>
>>>
>>> So, technically, a `noreturn` variable is impossible to 
>>> initialize. But since the compiler knows that the behavior of 
>>> the program can't possibly depend on the variable's value, it 
>>> is free to just skip the initialization altogether and leave 
>>> the variable uninitialized instead.
>> 
>> Sounds like "alias x = noreturn.init;"
>> 
>>>
>>> I guess you could make an argument that you should have to 
>>> write `noreturn x = void;` every time you declare a 
>>> `noreturn` variable. But even then, it would not be correct 
>>> for `noreturn x;` to result in an `assert(0)` at runtime--it 
>>> would have to be a *compile-time* error.
>> 
>> I think it depends on the definition of local declaration. For 
>> statics, it is obviously a compile-time error. For locals, my 
>> feeling is it should be a runtime error, but who knows. Timon, 
>> help.
>
> In D, types that do not have a default constructor cannot be 
> default-constructed. The question is whether `noreturn`, the 
> empty type, should really have a default constructor (that 
> immediately terminates the program). As far as I understand, 
> according to the DIP, `noreturn` has a default constructor, but 
> `noreturn` variables are initialized lazily when they are 
> accessed. I am not sure whether that's pragmatically the right 
> choice, because it's a special case and generic code might 
> check whether some type is default-constructible and only in 
> this case declare a local variable of that type. At least it 
> crashes at the latest possible moment, I guess. It's certainly 
> a bit weird that now, in D, 0·x is not always 0.

Thanks, Timon! Don't construe the lack of a reply as disrespect. 
I'm slow, uneducated and still thinking.