# Adding Either type to the Standard Library

**URL:** <https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972>\
**Category:** Discussion\
**Tags:** stdlib\
**Created:** [May 28, 2020, 7:00pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972 "2020-05-28T19:00:24Z")\
**Posts on this page:** 1\
**Showing post:** 97

<div class="post-metadata">

**Author:** ![filip-sakel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/filip-sakel/32/8697_2.png) [@filip-sakel](https://forums.swift.org/u/filip-sakel)\
**Post date:** [June 4, 2020, 11:21am UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/97 "2020-06-04T11:21:03Z")

</div>

I think @Dmitriy_Ignatyev lays out pretty compelling reasons for `Either`'s addition:

> [@Dmitriy\_Ignatyev](#):
>
> Great idea😃. Having Either\<First, Second\> Type in Standard Library allows us to use the same type across libraries. Similar situation was with the Result\<Success, Failure\> Type.
> 
> Either type is very useful with UDF / Rx / Combine and other cases. Some examples:
> 
> ```
> let completion: (Result<Either<AuthAgreement, ActiveLogin>, Error>) -> Void
> func eitherRequest<L, R>(_ target: Target,
> completion: @escaping NetworkCompletion<Either<L, R>>)
> 
> let quizScoreViewModel: Either<ScoreViewModel, String>
> let quizAnswer: Either<String, [QuizAnswerVariant]>
> let showError: Either<ErrorVM, TextSheetVM>
> 
> ```

I feel like a need to clarify that `Either` won't try to replace all 2-case enums and neither will `OneOf` replace all enums, just as Tuples haven't replaced `struct`s. Tuples still have labels and they are more concise, still though `struct`s are usually preferred. `Either` just as Tuples, fits naturally in places where the creation of a new type just doesn't make sense. For example, such a type is present in the Standard Library, in the ["automatic protocol satisfaction"](https://forums.swift.org/t/automatic-requirement-satisfaction-in-plain-swift/37158) proposal, in function builders it would make sense if it was used instead of two separate - and confusing - `buildEither` methods. Additionally, in places where the creation of a new type is currently not allowed:

```swift
struct FooGeneric {
    func fooGeneric<Baz>(baz: Baz) {
        enum State { case bar(Bar), case foo(Foo) } // ❌ 

        ...
    }
}

```

of course we can do:

```swift
struct FooGeneric {
    enum State { case bar(Bar), case foo(Foo) }

    func fooGeneric<Baz>(baz: Baz) {
        ...
    }
}

```

but in the above cases if we use State just in fooGeneric it would make much more sense for an `Either` type to take `State`'s place. Not to mention the boilerplate that would be required should we want `Equatable` conformance.

I recognise that `Either` is not the ideal type, we'd all like to have. Nonetheless, I feel that it is needed for the cases outlined above - or at least it would make them more pleasant to deal with. Finally, let's not forget that having an `OneOf` as I mentioned before, is not an option currently, so adding `Either` for now seems like a good option and discussing how to best implement is the goal of this discussion. If you have any other ideas that are realistic for the above examples and is more elegant than Either feel free to share them.

---

_[View the full topic](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972)._