> And if it is a class, or even method: it is violating SRP. Not always! Somebody is going to have to discriminate on the argument, and if indeed the caller al

> And if it is a class, or even method: it is violating SRP. Not always! Somebody is going to have to discriminate on the argument, and if indeed the caller already knows what they're providing, there's no need to wrap it in an Either -- there should be individual methods for both variants. But if the caller doesn't know what it is yet, and the type represents a domain concept that happens to be a set of options, then there's no reason the caller has to busy itself with that knowledge. To the caller, this might be (actually or morally) an opaque type, and the callee may be where knowledge about it is centralized, and hence where discriminating on the variants ought to happen. The single-responsibility principle is definitely something that always needs to be kept in mind, but it's not something that can be replaced with broad rules, either. > If it is a return-type, there too: why not [...] do like Rust: make it an `Option<Some, None>: user` or a `Result<Ok, Err>: user`, the typing now contains this "either/or" not the variable names; That's exactly what they did -- in the ML-like syntax they used, their `PersonOrError` is exactly `Either<Person, Err>`, but with the type arguments pre-instantiated. type PersonOrError1 = | P of Person | E of Error type 'l 'r either = | Left of 'l | Right of r type PersonOrError2 = Person Error either