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

[Timon Gehr]

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.