Allowing zero-sized structs makes things easier for automatically-generated code, because the code generator doesn't need to treat this as a special case that it must avoid. Similar considerations apply to zero-length arrays, functions with no variables, etc.

Where many people notice this kind of problem is when they generate SQL, and they're generating WHERE column IN (<list of values>) dynamically. SQL doesn't allow the degenerate case of an empty list; if their source data has an empty list, they have to take special measures to address this (one approach I've used is to add an "impossible" value to the source list before filling it into the template, another is to conditionalize adding this condition to the WHERE clause).

For use in generics

Consider code like this:

trait Message { fn print(&self) -> String } fn print_message<T: Message>(message: T) { print!("{}", T.print()); } struct EmptyMessage; impl Message for EmptyMessage { fn print(&self) -> String { "".to_string() } } 

In this case, EmptyMessage isn't actually really a struct, since it has no size. It's just used to indicate a certain behavior.

At runtime the entire struct will be completely optimized away, yet it's useful so we don't need to define separate functions depending on if the type actually needs any data to do it's work or no.

For a look at more advanced cases check out the Bevy game engine, which extensively uses unit structs as parameters to generics, even if the struct doesn't even implement any custom methods.

If it has methods or computed properties

Consider this most basic of SwiftUI views:

struct ExampleView: View { var body: some View { Text("Hello, World!") } } 

It has "zero" size, but its vtable is important.

Regularity

A number of specific arguments have been provided, but I believe that a more generic argument applies here, and in many other situations: regularity is good.

For example, if we take a (relatively) immature language such as Rust, you'll notice that part of the difficulties for newcomers are that some things are available in some contexts, but not others.

Commas are easy:

// A trailing comma is allowed after the last argument of a function. fn foo(a: A, b: B,); // A trailing comma is allowed after the last argument of a call. foo(a, b,); // A trailing comma is allowed after the last field of a struct. struct Foo { a: A, b: B, } 

Generics are getting better:

// A type alias can be generic. type InlineVec<T, const N: usize> = Vec<T, InlineSingleStore<T, N>>; trait X { // An associated type can only be generic from 1.65 forward (yeah!). type Inline/*<T, const N: usize>*/; } 

Compile-time callable (const) are still iffy:

// A free-function can be marked `const`, and evaluated at compile-time. const fn foo() -> i32; impl S { // An associated function of a struct can be marked `const`. const fn bar(&self) -> i32; } trait X { // An associated function of a trait cannot be marked `const`. /*const*/ fn baz(&self) -> i32; } // Instead, a trait _implementation_ can be marked `const`, // but only if the trait declaration was tagged `#[const_trait]`. impl const X for S { fn baz(&self) -> i32 { 4 } } 

There are good reasons for this -- design and implementation complexity, notably -- however from a user point of view it's jarring. It's a myriad rules to remember.

Regularity, or Orthogonality, as in the ability to apply a concept everywhere it is sensible to, makes for a simpler language to use.

Thus, the question should be: Why would a language not allow X?

(ie, what advantage is there is NOT providing X?)

Out of symmetry, if it has templates that allow you to pass void as an argument. In that case, you'd end up with means to create zero-sized structs anyway. Also, you can use them as markers for variable length content provided by subtypes, if the language has such types.

C99 allows for a Flexible array member to allow a variable length array to be allocated at the last member of a structure. This can simplify dynamic allocation of a structure which ends with a variable length array since the compiler will adding to ensure the flexible array type to have the correct starting alignment.

GCC allowed Arrays of Length Zero as extension prior to the C99 Flexible array member.

Here's one that doesn't actually apply to Rust but which nearly applies to Rust.

As a compile-time token, to help the programmer manage lifetimes or satisfy other ordering constraints. Here's some pseudocode:

type Token = private {} fun obtainToken() : Token = // some side-effectful stuff here, then… new Token {} fun doGuardedThing(_token: Token) = // some stuff that is guaranteed only to happen // if you've called `obtainToken` already 

Sure, it's not exactly common to have literally no data to pass around in the token, but I've certainly wanted to do this before. If you've only got one zero-sized type (the unit type), then you can't guarantee that someone obtained your token through your desired API: any caller is free to magic up a value of type () anyway.

You can instead solve this problem with a single-case enum, but that takes space at runtime unless you're holding a zero-sized type anyway, which just punts the problem down the line: enum cases have the same visibility as their containing type, in Rust.

(The reason this doesn't apply to Rust in real life is because you can actually construct a Foo {} even if pub struct Foo = {}. The workaround, I guess, is pub struct Foo = { garbage: () }, or a PhantomData. I'm really considering a hypothetical language which had something more like F#'s visibility modifiers.)

Having named zero-sized types is useful to create handles to resources that are fixed at compile-time. This pattern comes up a lot in embedded systems / bare-metal programming, for example. The system has a fixed amount of resources and peripherals, often at fixed addresses or specific CPU instructions; a library that provides bindings to the peripheral can create a handle to represent that resource.

For example:

pub struct Rng { _private: (), } 

The _private field makes it impossible for library users to construct it, so they must obtain the handle through a constructor function in the peripheral library. The peripheral library can use this to track how many handles exist. For example, it's often used to guarantee unique "ownership" of the resource, by only providing one handle to the library user:

impl Rng { pub fn take() -> Option<Self> { // This doesn't quite work; simplified for demonstration purposes static mut TAKEN = false; if TAKEN { None } else { TAKEN = true; Some(Self { _private: () }) } } } 

The handle to the peripheral doesn't need to store any runtime references, since the peripheral address is known at compile-time. Most of the time, it also doesn't need to store any state - it just provides functions to conveniently, directly access the peripheral's I/O:

const RNG_ADDR: *const u32 = 0x48021800 as *const u32; impl Rng { pub fn read(&mut self) -> u32 { unsafe { RNG_ADDR.read_volatile() } } } 

Therefore, it only makes sense that it takes up no memory. It's just a marker used at compile-time to check who has control over that resource at that point in the program.

For a practical example, see the stm32f0 crate. Most peripheral-access crates (PACs) look like this. The entrypoint is usually Peripherals::take(), which provides the Peripherals collection exactly once to the first caller.

There are many good examples in the other responses about why this might be a reasonable thing to do in some cases, so I won't repeat those.

But I'd like to add that I think the premise of the question has it backwards. You ask:

This would still seem pretty useless though ... what justification do existing languages with this feature provide?

This reminds me of an old joke: "The difference between Country A and Country B is that in A, everything that is not explicitly permitted is forbidden, whereas in B, everything that is not explicitly forbidden is permitted."

Your question presumes that the right default for language designers is that supporting an interaction of features has to be justified, rather than requiring justification to prohibit an interaction of features. There are several reasons this premise is backwards.

• Lack of imagination. One can find many, many examples of prohibitions in complex systems that are based on naive notions of "no one would ever need that" or "that's always a mistake."

• Complexity. Languages that have lots of rules that constrain interactions between features tend to have more accidental complexity, which increases cognitive load on developers.

As an example, imagine you have a language with properties, and a defined concept of "getter" and "setter". You will surely find someone who thinks the combination of "setter but no getter" (or "public setter, private getter") is silly enough to be outlawed, but that guy is almost always wrong. You do your users no favors by baking "style guide" opinions into the language.

So, it is great to ask the question "are there good uses for zero-sized structs?" (And as the other answers show, there are.) But we should be on the lookout for coupling that with "and, if not, shouldn't we restrict them?"

Language designers should give users tools that work together in predictable and useful ways. Not all combinations are as useful as others; that's fine.

Zero-sized structs could be used to force changes to the alignment of members of a containing struct. This is more likely when the object is a primitive and not an object.

struct { type_a a[2]; // Potential padding here type_b b[0]; // Potential padding here type_c c[10]; } d; 

For when you need a value, but don't care about the actual value

Go allows empty structs (struct{}). Its main use is with the built-in map type for imitating sets, where the value of the map isn't needed:

eles := []string{ ... } set := make(map[string]struct{}) for _,e := range eles { if _,ok := set[e]; !ok { set[e] = struct{} // add the element to the set } } for k,_ := range set { // do stuff with k, which is a unique element of eles } 

and with channels, as a signal with a small size:

import ("time";"fmt") signal := make(chan struct{}) // read-write channel go func() { time.Sleep(2*time.Second) signal <- struct{} // tell the outside world we're done } for { select { case <-signal: fmt.Println("Waited 2 seconds") break // exit loop default: fmt.Println("Waiting...") time.Sleep(time.Second / 2) } } 

For trait implementations

They can be useful for getting a concrete implementation of a trait. For example, see this example in the Rust design patterns book:

// The data we will visit mod ast { pub enum Stmt { Expr(Expr), Let(Name, Expr), } pub struct Name { value: String, } pub enum Expr { IntLit(i64), Add(Box<Expr>, Box<Expr>), Sub(Box<Expr>, Box<Expr>), } } // The abstract visitor mod visit { use ast::*; pub trait Visitor<T> { fn visit_name(&mut self, n: &Name) -> T; fn visit_stmt(&mut self, s: &Stmt) -> T; fn visit_expr(&mut self, e: &Expr) -> T; } } use visit::*; use ast::*; // An example concrete implementation - walks the AST interpreting it as code. struct Interpreter; impl Visitor<i64> for Interpreter { fn visit_name(&mut self, n: &Name) -> i64 { panic!() } fn visit_stmt(&mut self, s: &Stmt) -> i64 { match *s { Stmt::Expr(ref e) => self.visit_expr(e), Stmt::Let(..) => unimplemented!(), } } fn visit_expr(&mut self, e: &Expr) -> i64 { match *e { Expr::IntLit(n) => n, Expr::Add(ref lhs, ref rhs) => self.visit_expr(lhs) + self.visit_expr(rhs), Expr::Sub(ref lhs, ref rhs) => self.visit_expr(lhs) - self.visit_expr(rhs), } } } 

Note the zero-sized Interpreter struct in the code. It is solely used for the implementation and instantiation of the Visitor trait.

Consider Option types.

Some a struct with a backed field. None is a zero size struct.

The usefulness of None is that it can participate in type casts.

A language can recognize that zero-size structs can be singleton, so you could distinguish Some from None via a pointer check.

Some runtimes instead store out-of-band type information when a struct is up-cast to an abstract type. Go for example does this so that it can check that down-casts from interface types are safe.

Meta Typing

Another reason i didn't found in the answers are zero cost meta typing. I will use meta code to better show it because even though it is rust specific, the question are a general one.

lets take a ML (meta language) like language.

type 'T Stream = { ty: 'T stream: IOhandle // pseudonym for any input point from the kernel. } // assumed zero types type Readable = {} type Writable = {} let Read (src: Readable Stream) = src.stream.Read() let Write (dst: Writable Stream) item = dst.stream.Write item 

In this example, we use zero size types to enforce code behavior into type checking. since Readable and Writable both are zero types, we end up with two types that by the compiler is different in types, hence we can ensure by type that we not by mistake passes a stream that is readable into the write function. But also because the two Readable and Writable are zero types, they are dropped afterward by the compiler in optimization phases, because the information they hold are purely type/expected behavior based.

This is very useful when coding programs which need to be secure or has a very low tolerance of error in end product. It will eliminate a lot of common error not normally addressed by the type system or check for by the compiler. This leads to less need of testing, because the compiler by compiling the code without error are proof that it will behave correct, since behavior are encoded into the types.