Proposal: Non-exhaustive tagged unions

[tadeokondrak]

Currently, tagged unions with a non-exhaustive enum tag don't have the forwards-compatibility features in switches, because it's impossible to create a non-existent union value.

From the non-exhaustive enums proposal:

A non-exhaustive enum is an enum that may have other unknown members.
This can help create APIs that may be extended in future. This sort of thing frequently comes up in data formats, network protocols, and even C APIs.

Non-exhaustive tagged unions can be useful in pure Zig APIs where new variants can be added, but breaking user code on updates is undesirable.

[ifreund]

For what it's worth, I have a real world use-case for this in zig-wayland. The only alternative I see is making basically everything in the API generic over the version, which seems very heavy handed.

[SpexGuy]

How would this work? Are unnamed values implicitly void or is there a way to attach payload types to them? If the latter, how is the size of the union determined?

[tadeokondrak]

How would this work? Are unnamed values implicitly void or is there a way to attach payload types to them? If the latter, how is the size of the union determined?

It isn't meant to be ABI forwards-compatible like non-exhaustive enums.
The purpose is to make a user of the type decide between else => {} (staying forwards-compatible) and _ => {} (rejecting it, meaning possible compile errors on library updates).

I don't think it should be possible to create an unnamed/invalid value, so actually hitting the _ branch would be illegal behaviour.
That means any code inside the switch would be unreachable, so maybe clearer syntax for that could be added:

switch (x) {
    .a => |a| {},
    .b => |b| {},
    _,
}

[Vexu]

This feature has been implemented in #8163, which can be quickly updated if this is accepted.