defining zero-sized structs

[nikomatsakis]

From #31:

"If you have a struct which -- transitively -- contains no data of non-zero size, then the size of that struct will be zero as well. These zero-sized structs appear frequently as exceptions in other layout considerations (e.g., single-field structs). An example of such a struct is std::marker::PhantomData."

Is that a sufficient definition for zero-sized structs? This seems like an important guarantee that we frequently rely upon for performance and other purposes, so it is worth specifying.

[hanna-kruppe]

I'd rather spell out exactly the structural recursion that is going rather than hand wave it away with "transitively", but yes I think we should guarantee:

• Arrays are ZSTs if the count is zero or the element type is ZST
• A tuple is ZST if all elements are ZST
• A struct is ZST if all fields are ZST
• Empty enums are ZSTs

Enums are interesting because we could try to be smart around enums with a single variant but that will likely depend on the repr attribute which doesn't seem the case for structs (#[repr(C)] struct Foo {} is currently a ZST).

[asajeffrey]

What about a one-case enum whose body is zero-sized, e.g.:

enum Foo { OnlyCase(SomethingZeroSized) }

or a union all of whose cases are zero-sized?

[hanna-kruppe]

The only-variant-containing-ZST case could also be defined as ZST depending on repr attributes, but doesn't seem very useful.

Unions, good point, could probably be treated the same as structs, i.e., could be ZSTs even with repr(C).

[rodrimati1992]

Generic enums with 2 or more variants are zero-sized if every variant is Void except for a zero-sized variant.
https://play.rust-lang.org/?gist=0b3278bdd497b1bc3c9bccbb4ca828df&version=stable&mode=debug&edition=2015

[Mark-Simulacrum]

Empty enums are ZSTs

Aren't empty enums considered uninhabited? I'm not sure if those types are technically ZSTs since there's no actual valid representation.

[hanna-kruppe]

@rodrimati1992 True, but I'd rather leave that sort of reasoning out of the picture for the initial step because:

• We would presumably want to generalize it to uninhabited types more generally rather than special case enum Void {}, but the exact definition of uninhabitedness is still under discussion (e.g., Less conservative uninhabitedness check rust#54125)
• Until relatively recently we've been very wrong about the interaction of inhabitedness and type sizes (Uninhabited types are ZSTs despite partial initialization being allowed in safe code. rust#49298)
• We do not have to document exactly when rustc currently makes something zero-sized, on the contrary we can document a rather small set of ZSTs and expand that set in the future

@Mark-Simulacrum Empty enums are indeed uninhabited, but uninhabited types still have a size -- which is not necessarily zero, but definitely should be zero for empty enums.

[RalfJung]

Aren't empty enums considered uninhabited? I'm not sure if those types are technically ZSTs since there's no actual valid representation.

They are ZSTs in the sense that their size is 0 (layout.is_zst()). They are moreover uninhabited (layout.abi.is_uninhabited()). I think the latter currently implies the former, and that seems like a fairly reasonable axiom to me.

EDIT: Or maybe not, since we probably do consider (!, i32) to be uninhabited but cannot make it a ZST as @rkruppe reminded me.

[nikomatsakis]

I'd rather spell out exactly the structural recursion that is going rather than hand wave it away with "transitively", but yes I think we should guarantee:

This seems reasonable, except that it seems .. fine to say something stronger about enums (e.g., that an enum is zero-sized if it has only one "inhabited" variant and that variant is zero-sized). However, you are correct that we can "start small" (no pun intended) and grow, so perhaps we should just leave a "footnote" of some sort about that (in particular since I don't care to define inhabited just now).

[nikomatsakis]

It seems to me that the full text of this section ought to include notes about uninhabitedness and its connection to size as well.

[nikomatsakis]

I am wondering if we ought to pull "zero-sized types" into a section all its own, since it seems a bit .. cross-cutting?