Layout of uninhabited types

[gnzlbg]

We don't define the layout of uninhabited types anywhere.

We probably want to define that ! and enum Void {} have zero size, but as pointed out in #37, (!, i32) is uninhabited but does not have zero-size.

We should probably expand the struct, enum, union, and array sections with a sub-section about when are these types uninhabited, and what their layout is in this case.

[hanna-kruppe]

We should describe when types are considered uninhabited, but I don't see any reason to special case layout of uninhabited types: there is no general relation between inhabitedness and (mentioning everything that anyone ever proposed as part of layout):

• size (as you noted)
• alignment
• offsets of fields
• call ABI, necessarily (passing values of uninhabited type is UB, so their call ABI is irrelevant)

So the layout rules should largely be the same for inhabited and uninhabited types. The one possible exception is that perhaps the niche for uninhabited types becomes maximal, but we'd have to be careful there for the same reasons e.g. (!, i32) is not a ZST (the i32 portion can be written and potentially also read).

[RalfJung]

I think for Rust, "uninhabited" is a particular "call ABI": https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/layout/enum.Abi.html#variant.Uninhabited.

We should describe when types are considered uninhabited

Agreed. We should also define the term precisely, because there are many kinds of "uninhabited" in Rust. Some types have "uninhabited" call ABI, some have no value satisfying the validity invariant, some have no value satisfying the safety invariant.

[JakobDegen]

Closing this as broadly decided. Someone could ask T-lang to guarantee a size of zero if that isn't documented yet

[RalfJung]

I'll open a new issue for the sub-question of enums with uninhabited variants.

EDIT: #443