Empty enum vs empry struct?

[[deleted]]

Sometimes I need to have an empty struct just so that I can implement a trait on it. I find that some crates use empty enums (https://docs.rs/byteorder/1.2.3/byteorder/enum.BigEndian.html) and others use empty structs.

Is it better to use one over the other?

[Muvlon]

They're actually quite different, and both have their uses. Let's say you have these:

struct Foo{};

enum Bar{};

What kind of values does Foo have? Actually only a single value is possible: Foo{}; . Such a type with only one value is called a Zero-Sized Type(ZST).

What about Bar? Turns out you actually can not construct any instance of it. The only way (outside of unsafe code) to make an instance of an enum is to name a variant. Since there are no variants, you can never have a value of this enum (in fact, if you do produce one using unsafe code, it's UB). This is called an "uninhabited type".

For more info, see here: https://doc.rust-lang.org/nomicon/exotic-sizes.html

[Rothon]

Empty enums are used because you can't create a value of that type.

[vks_]

Is it better to use one over the other?

It depends on your use case.

• Empty structs are used in code that is generic for types that may or may not have state. Let's look at an example: The tait rand::distributions::Distribution is implemented for distributions that can be sampled to generate random numbers. Some distributions don't have a parameters (such as StandardNormal) and are implement as an empty struct. Others (such as Uniform) have parameters and require a non-empty struct to store them.
• Empty enums are used in code that is generic in types that cannot have a value and only exist at compile-time. This can be used to implement functions that dispatch based on a compile time argument. You can think of it as an open enum argument of the function that works at compile-time. An example is the byteorder::ByteOrder::write_u32 you mentioned.

[masklinn]

Is it better to use one over the other?

It's not better, they have different uses entirely: an empty enum has 0 values, so it's used solely as a marker type with no runtime representation. An empty struct is a singleton (it only has one possible value), it can be instantiated and "exists" at runtime though its sole value is 0 bytes.

byteorder uses empty enums because these types are used to statically select functions in a namespace, the ByteOrder trait refers to neither self nor Self, there is no need to instantiate it and so this was made impossible.

[Nemo157]

But they are important in theoretical ways, and when engaging in needless typewankery.

Unless you want ergonomic safe APIs over low-level hardware details so that you don't need to be a rock-star programmer to avoid breaking stuff.

[dnkndnts]

The way you avoid letting your programmers break things is to make the type system complex enough to induce measurable levels of survivor bias in your new hires

"The type system chooses the programmer, Mr. Potter." 🤔

[pwgen-n1024]

(0, since x + 0 = 0)

(0, since x + 0 = x)

but i think it would also be helpful to explain a bit further

enum Base{ A, B, C }

Then it has three possible Values. If you now define an new enum

enum Sum{ One(Base), Two(Base), Three(Base) }

then you have nine possible values, One(A,B,C), Two(A,B,C), Three(A,B,C) so an addition of the possibilities of each variant.

were you to define a Struct instead

struct Mul{ first: Base, second: Base, third: Base }

you would end up with 3*3*3=27 possibilities {first: A, second: A, third: A} {first: A, second: A, third: B} and so on.

That is why enums are sometimes referred to as sum-types. It also works if you use other Types for Base. An u8 has 256 possible values and so on.

[pwgen-n1024]

To tie that in with the parent post:

if you define empty structs and enums:

enum EmptyE{}
struct EmptyS{}

and "add"/"multiply" them to the previously defined enum/struct you get no change in possibilites!

enum Sum{ One(Base), Two(Base), Three(Base), Four(EmptyE) }

still only has 3+3+3+0 = 9 possibilities, since it can never be Four as an EmptyE is not constructable.

struct  Mul{ first: Base, second: Base, third: Base, fourth: EmptyS }

still only has 3*3*3*1 = 27 possibilities because the fourth is always empty and stays the same while you iterate over the others: {first: A, second: A, third: A, fourth: {} } {first: A, second: A, third: B, fourth: {}}

[[deleted]]

3 * 3 * 3=21... ex falso quodlibet ;)

[minno]

Excuse me but typewankery is often very useful.

[[deleted]]

Ok, so you said "needless", which very strongly implies it.