Either: a general purpose two-case sum type for Rust
The enum Either with variants Left and Right is a general purpose sum type with two cases.
At a glance
- What is it?
- The either crate is a small Rust enum with Left and Right variants, offering Option-like and Result-like methods, Iterator and IO trait implementations, and no_std support. It suits a library that needs a two-variant sum without deciding what the variants mean.
- Who is it for?
- Either is worth using when a two-case sum is genuinely part of your interface rather than an internal detail, because it gives you a name for the two cases that Option and Result will not give you, because the macros make the short-circuiting style work without a bespoke error type, and because the crate is small, dual licensed and usable without the standard library. It is the wrong tool for success and failure, and the crate says so itself.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 17 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Either is, and the sentence that keeps people from misusing it
The enum Either with variants Left and Right is a general purpose sum type with two cases, and that is the whole definition.
A sum type is a value that is one of several alternatives, and unlike a tuple or a struct, a two-case sum is something the compiler can reason about: a match on it is exhaustive with two arms, and you cannot accidentally treat the left case as if it were the right one.
The crate gives you methods that are similar to Option and Result, and it also implements traits like Iterator, Read and Write. The crate includes macros try_left!() and try_right!() to use for short-circuiting logic, similar to how the ? operator is used with Result.
Then there is the sentence that matters most, and it is short: Note that Either is general purpose and unopinionated about the meaning of Left and Right. For describing success or error, use the regular Result.
That is a library author telling you, in the documentation, that the most common misapplication of their type is the wrong one. Either does not mean failure. It does not mean the left branch is the happy path. It carries no meaning at all beyond being the first or the second case, which is exactly what makes it useful in the cases where Option and Result are too opinionated, and exactly what makes it a poor fit for a success and failure pair where the reader expects the standard vocabulary.
Adding it to a project is a normal Cargo dependency:
[dependencies]
either = "1"The type lives in the rayon-rs organisation, which is the group behind Rayon, the data parallelism library. That is a reasonable place for a small general-purpose utility to end up, since Rayon's own internals have needed a two-case sum more than once, but it does mean the crate is maintained by people whose primary interest is elsewhere.
The API, and how it lines up with Option and Result
The interesting design work in Either is in making a type that is not Option or Result still feel familiar to a Rust developer.
The methods are described as similar to Option and Result, which means the shape of the API is the one a programmer already has in their head. A method that maps one side and leaves the other alone, a method that folds both sides into a single value, a method that turns a Left into something else, all of these exist in one form or another on Option and Result, and Either mirrors them.
The difference is that Option has one interesting case and None, and Result has Ok and Err, and both of those assign meaning to their variants. Either assigns none, so its methods cannot be as specialised, and that is a feature for a general purpose type. An Either returned by a function does not tell the caller what to do with it, and the caller has to know from context, which is the honest position for a type that means only one of two things.
The trait implementations are where Either is less common. Implementing Iterator means an Either can sit in a chain of iterators, and the implementation has to make a decision about what the left variant iterates as. Implementing Read and Write means an Either can be used where a stream is expected, which is the same kind of convenience, and the same kind of decision.
The macros are the part that makes the type usable in real code. try_left!() and try_right!() give you the short-circuiting behaviour of the ? operator when you are working with Either rather than Result. The ? operator is defined in terms of a From conversion, so it works with any error type, but a macro gets around the need for the error type to be convertible in the way ? requires. If your left case means one thing and your right case means another, and neither is an error in the Result sense, then a macro that returns early from the enclosing function is exactly the tool you need, and it keeps the code shaped the way Result code is shaped.
no_std, features and the optional serde support
The packaging is small and modern, and it tells you where the crate is aimed.
The Cargo manifest names the package either at version 1.19.0, on edition 2021, with rust-version 1.63.0 as the declared minimum. The keywords are data-structure and no_std, and the categories are data-structures and no-std, so the crate is explicitly positioned for use without the standard library, which is the embedded and no_std Rust world.
The feature setup is where that shows. The default feature set is std, the std feature itself is empty, and there is a use_std feature described in the manifest as a deprecated alias. That last detail is a small piece of history preserved in the build configuration: an older name for the same feature is kept working so that existing Cargo.toml files do not break, and the manifest marks it deprecated so the next person to see it knows what to do.
The only dependency is serde, and it is optional, with default features off and the alloc and derive features enabled. There is no other runtime dependency, which for a type crate is the ideal outcome, since a type in your public API is a dependency your users inherit.
The serde support is wired into the documentation metadata as well. The package.metadata.docs.rs section lists features = ["serde"], and the package.metadata.playground section does the same, which means the docs.rs build and the Rust Playground both compile the crate with the optional feature enabled so that the serialisation code appears in the rendered documentation and the crate can be tried online with its full API.
That is a small thing that shows care, because a feature that is not visible in the docs is a feature nobody uses, and the doc test coverage in the same repository would not exercise it either.
Releases, the version history and the release tooling
The repository is small: a src/ directory, a README, a RELEASES.md file, a LICENSE-APACHE and a LICENSE-MIT, and a Cargo.toml.
The RELEASES.md file is where the version history lives, and the documentation points you at it rather than at a changelog on a hosting site. There are no GitHub releases, which is the normal arrangement for a crate published to a registry, and it means the release history a user sees is the one in the repository.
The manifest carries the release configuration in the package.metadata.release section, and it is worth reading because it shows how the releases are produced. The allow-branch is set to main, so a release is only cut from that branch. The sign-tag setting is true, which means the tag is cryptographically signed, and the tag-name template is the version, so the tag and the crate version are the same string by construction rather than by convention.
That is a coherent, automated release setup, and the effect is that a version bump in Cargo.toml becomes a signed tag and a published crate without a human copying numbers around, which is how version mismatches get into the ecosystem in the first place.
The licence is dual, and the README says it in the terms a Rust user expects: dual-licensed to be compatible with the Rust project, licensed under the Apache License, Version 2.0 or the MIT license, at your option. Both licence files are in the tree.
The minimum Rust version is worth a note too. The badge says minimum rustc 1.63 and the manifest sets rust-version = "1.63.0", which is a long-standing version from 2022. That is a generous floor for a crate this small, and it means the crate can be used in projects that are pinned to an older toolchain, which is exactly the situation an embedded or no_std project is often in.
Where Either is the wrong tool
The first limit is the one the documentation states, and it is worth restating because the mistake is common. If your two cases are success and failure, use Result. Either is unopinionated about the meaning of Left and Right, so a function returning Either tells its reader nothing, and a reader who sees Result knows to look for the error case. Using Either there trades a shared convention for a local one, and the convention is worth more.
The second is that a general purpose type can be a general purpose liability. Because Either means only one of two things, every function that takes one has to document what Left and Right mean in its particular case, and the type system will not catch a caller that passes a Left meaning something else. Result and Option have the same problem in a milder form, but not enough of it to be worth giving up the vocabulary.
The third is the trait implementations and what they imply. Implementing Iterator for Either means the library has to decide what iterating a left value means, and that decision is baked into every user of the crate. The same applies to Read and Write. These are the right choices for a general purpose type, and they are also the places where a type that is unopinionated about its variants has to be opinionated about something, which is a good place to look before you depend on it.
The fourth is the dependency question. The type is small enough to define in your own crate in a dozen lines, and a widely used type is a widely used semver commitment. Adopting Either is a decision to take on someone else's release cadence and API decisions, in exchange for a shared vocabulary and the macros. For a type used in a public API of a library, the vocabulary argument is strong. For a type used internally in one crate, defining your own is often the better trade.
And the fifth is the maintenance concentration. The crate sits in the rayon-rs organisation, maintained alongside a data parallelism library, with a small number of people responsible. The last push to the repository was on 2026-10-06, so it is being worked on, and the release tags show no GitHub releases, so the version history lives in a file in the repository. None of that is alarming for a crate this stable, and it is worth remembering that a mature type crate is usually less work to depend on than to reimplement.
Editorial conclusion
Either is worth using when a two-case sum is genuinely part of your interface rather than an internal detail, because it gives you a name for the two cases that Option and Result will not give you, because the macros make the short-circuiting style work without a bespoke error type, and because the crate is small, dual licensed and usable without the standard library. It is the wrong tool for success and failure, and the crate says so itself. Before you add the dependency, check three things: that your two cases are not success and error, because the documentation is explicit that for describing success or error you should use the regular Result, and choosing Either there will confuse every reader; that you can live with the minimum Rust version of 1.63.0, which is old enough to be generous but is a floor you have to check against your own toolchain; and that you want a dependency at all, because the type is a handful of lines and the question is whether the shared vocabulary of a well-known crate is worth more than owning the definition.
Frequently asked questions
What is the Either type in Rust and when should I use it?
Either is a general purpose sum type with two variants, Left and Right, with methods similar to Option and Result and implementations of traits like Iterator, Read and Write. The documentation is explicit that it is unopinionated about the meaning of Left and Right, and that for describing success or error you should use the regular Result instead.
How do I add the either crate to a Cargo project?
Add either = "1" under the dependencies section of your Cargo.toml. The current version is 1.19.0, the minimum supported Rust version is 1.63.0, and the crate works without the standard library because the default feature set is std and the crate is published with the no-std category.
What are the try_left! and try_right! macros for?
They are for short-circuiting logic, similar to how the ? operator is used with Result. They let a function return early when the value is on the side you are checking for, which is what makes Either practical in a function whose two cases are not success and error, where the ? operator does not apply directly.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/rayon-rs-either)Was this useful?