either

The `either` crate is exactly what it claims to be: a simple, well-designed enum for sum types. From a security perspective, this is exemplary - zero dependencies means zero supply chain risk, and the crate's simplicity makes it trivial to audit. The entire implementation is straightforward Rust with no unsafe code, no network operations, no crypto to misconfigure.

In daily use, `Either` is a workhorse for cases where `Result` or `Option` semantics don't quite fit. The iterator adaptors and trait implementations (Iterator, From, AsRef, etc.) make it ergonomic to work with. Error handling is non-existent because there's nothing that can fail - it's pure data modeling. The type system does all the heavy lifting, and compiler errors guide you correctly.

The crate follows secure-by-default principles perfectly: no configuration, no defaults to get wrong, no panics in normal use. It's impossible to misuse in a way that creates security vulnerabilities. The API is so minimal and well-constrained that input validation happens naturally through Rust's type system.

From a security perspective, `either` is exemplary precisely because it does so little. It's a zero-dependency crate that provides a simple enum wrapper with no unsafe code, no network I/O, no crypto, and no complex state management. This minimalism is a feature—there's virtually no attack surface to worry about.

In practice, I use `either` primarily for iterator adapters and function return types where I need to express "this or that" without reaching for Result or Option. The type implements all the standard traits you'd expect (Iterator, Debug, Serialize if features are enabled), making it completely transparent in most codebases. Error handling is a non-issue since it's just a container—any validation happens in your code, not the library.

The biggest security win is that this crate follows secure-by-default principles by being impossible to misuse. There are no configuration footguns, no hidden defaults that could leak information, and the API is so straightforward that code review is trivial. It's the kind of dependency you add once and never worry about in security audits.

The `either` crate does one thing exceptionally well: provides a simple `Either<L, R>` enum that feels native to Rust. In practice, it shines when you need to return two different types from iterator chains or when modeling domains where Left/Right semantics make sense. The iterator adapters are particularly well-designed—methods like `left_and_then` and `right_and_then` let you chain operations elegantly without constant pattern matching.

The type integrates seamlessly with Rust's ecosystem through comprehensive trait implementations (Debug, Clone, Iterator, etc.). IDE support is excellent with clear type inference and helpful autocomplete. Error messages are standard Rust compiler output, making debugging straightforward. The documentation is concise but covers the essential use cases with practical examples.

One limitation is the minimalist philosophy—there's no `map_left`/`map_right` convenience methods (you use `map_left` via `Either::map_left` or pattern matching). For complex error handling, you might want a Result-like type instead. The crate assumes you understand sum types; newcomers from languages without them may need to read up on the concept first.