# 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:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![ahti](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ahti/32/604_2.png) [@ahti](https://forums.swift.org/u/ahti)\
**Post date:** [June 3, 2020, 9:45am UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/81 "2020-06-03T09:45:12Z")

</div>

Would the requirement to cast in some way before being able to use a value not count as explicit projection? (I might be mixing out projection/injection? Also I'm assuming wrapping a value in a union type implicitly would not result in major type-checker problems?)

---

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [June 3, 2020, 11:04am UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/82 "2020-06-03T11:04:28Z")

</div>

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\>

Our implementation:

```swift
/// Either represents duality, a value that can either be of a type or another
public enum Either<L, R> {
  case left(L)
  case right(R)
}

extension Either {
  public var leftValue: L? {
    switch self {
    case .left(let leftValue): return leftValue
    case .right: return nil
    }
  }

  public var rightValue: R? {
    switch self {
    case .right(let rightValue): return rightValue
    case .left: return nil
    }
  }
}

extension Either where R: Error {
  public func asResult() -> Result<L, R> {
    switch self {
    case .left(let leftValue): return .success(leftValue)
    case .right(let rightValue): return .failure(rightValue)
    }
  }
}

extension Either where L: Error {
  public func asResult() -> Result<R, L> {
    switch self {
    case .left(let leftValue): return .failure(leftValue)
    case .right(let rightValue): return .success(rightValue)
    }
  }
}

extension Either: Equatable where L: Equatable, R: Equatable {}

extension Either: Hashable where L: Hashable, R: Hashable {}

extension Either: Decodable where L: Decodable, R: Decodable {
  public init(from decoder: Decoder) throws {
    do {
      let decodedInstance = try L(from: decoder)
      self = .left(decodedInstance)
    } catch let leftError {
      do {
        let decodedInstance = try R(from: decoder)
        self = .right(decodedInstance)
      } catch let rightError {
        let info = "Type: \(Self.self), \n left: \(String(reflecting: leftError))\nright: \(String(reflecting: rightError))"
        throw JsonMappingError(code: .typeCastFailed,
                               userInfo: ["EitherMappingFailed": info])
      }
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [June 3, 2020, 11:27am UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/83 "2020-06-03T11:27:33Z")

</div>

If we're going to push a simple `Either` type then I would prefer the `first` and `second` case names as they almost mirror the index based names of a potential variadic `OneOf` enum, except that they don't start with `zero`. Ultimately I still would prefer `OneOf` (but maybe with a different/better name) and would stop using `Either` immediately, even to represent duality.

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [June 3, 2020, 1:44pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/84 "2020-06-03T13:44:28Z")

</div>

To everyone discussing union types, subtyping and implicit conversions: please stop. The core team has made it abundantly clear that they do not believe this feature is a fit for Swift. They have provided very good reasons for this. Discussion in this direction is not helpful and distracts from discussion of directions that are viable and fill gaps in the language.

> [@John\_McCall](#):
>
> Many people who want anonymous sums seem to want both injection and projection to be implicit, which is very much not analogous to tuples and would cause quite a few type-checking problems. You could require labels to be written out in the type, although it would make the types a lot less concise.

Please don’t mix people who continue trying to push union types with those of us who are focused on trying to discuss structural sum types. Yes, a lot of people are attracted to the idea of union types. But that is not an argument against structural sum types. It demonstrates that people continue to need to be educated about why union types are not a fit for Swift.

> [@John\_McCall](#):
>
> I'm starting to lean towards providing an `Either` in the library.

The problem with `Either` is that it leaves us with either clunky nesting or our own `OneOf3`, `OneOf4`, etc. `Either` is a narrow solution. Many of the use cases I run into are in cases of composition which are best designed as variadic. The language should provide a solution that works in this context.

> [@DevAndArtist](#):
>
> If we're going to push a simple `Either` type

Please let’s not. Let’s focus on creating examples that demonstrate why structural sum types are a better approach.

---

<div class="post-metadata">

**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\
**Post date:** [June 3, 2020, 2:34pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/85 "2020-06-03T14:34:40Z")

</div>

> [@anandabits](#):
>
> To everyone discussing union types, subtyping and implicit conversions: please stop. The core team has made it abundantly clear that they do not believe this feature is a fit for Swift. They have provided very good reasons for this.

_Actually, I haven't even seen a convincing argument not to add support for `|` at type level…_

> [@anandabits](#):
>
> > [@DevAndArtist](#):
> >
> > If we're going to push a simple `Either` type
> 
> Please let’s not. Let’s focus on creating examples that demonstrate why structural sum types are a better approach.

Although I agree that a dedicated, unspecific `Either`-type isn't a good addition, that is what the thread starter wants to discuss here — and imho we should respect this request.

For a huge and complicated pitch, it might make sense start collecting reasons for dismissal upfront — but for a simple thing like `enum Either<First, Second>`, imho it is fine to focus on improvements and wait with negative feedback until review.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 3, 2020, 5:32pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/86 "2020-06-03T17:32:20Z")

</div>

`as?` could be used as the projection syntax, yes, and I believe that would not have particularly severe type-checking problems.

"Projection" was probably not the best word-choice here on my part; I just meant in general getting at the underlying values.

---

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [June 3, 2020, 5:35pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/87 "2020-06-03T17:35:59Z")

</div>

`as?` would still have the ambiguity problem when more than one tag in the sum has the same payload type, though.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 3, 2020, 5:36pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/88 "2020-06-03T17:36:17Z")

</div>

> [@Tino](#):
>
> Although I agree that a dedicated, unspecific `Either` -type isn't a good addition, that is what the thread starter wants to discuss here — and imho we should respect this request.

I completely agree. This thread has been overwhelmed by discussions of counter-proposals.

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [June 3, 2020, 5:46pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/89 "2020-06-03T17:46:56Z")

</div>

> [@John\_McCall](#):
>
> I completely agree. This thread has been overwhelmed by discussions of counter-proposals.

Would the core team prefer the community to start separate threads every time there are different fundamental approaches to solving the same problem? We could certainly do that, but what would the advantages be? Keeping the discussion in a single thread gives participants with different views more opportunity to interact, which I think is a healthy thing.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 3, 2020, 5:50pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/90 "2020-06-03T17:50:16Z")

</div>

I don't see a whole lot of interaction with the original proposal in here. It's 90% people discussing the language design of structural sum types. The `OneOf` I'm seeing described is essentially the same; it's not implementable without compiler magic because the cases somehow get different names.

---

<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 3, 2020, 5:52pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/91 "2020-06-03T17:52:17Z")

</div>

> [@Tino](#):
>
> Although I agree that a dedicated, unspecific `Either` -type isn't a good addition, that is what the thread starter wants to discuss here — and imho we should respect this request.

Thank you for understanding, but I should clarify something: I’m not against anything other than Either - after all that’s what discussion is all about. Nonetheless, I appreciate implementable proposals.

The possibility of adding OneOf, OneOf2... is worth exploring, but we should also consider what would happen when adding a variadic OneOf. Source might not break, but ABI might - I’m not really familiar with ABI stability so please correct me if I’m wrong. Also will library authors be willing to switch to the variadic OneOf once it comes out, or will OneOf3 become a typealias if it’s variadic counterpart? I think these are valid questions worth exploring when discussing currently implementable designs.

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [June 3, 2020, 6:28pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/92 "2020-06-03T18:28:39Z")

</div>

> [@Joe\_Groff](#):
>
> `as?` would still have the ambiguity problem when more than one tag in the sum has the same payload type, though.

Yes. In a generic context where types may be identical, it would create nasty particular cases:

```swift
struct Stuff<Left, Right> {
    var value: Left | Right

    var left: Left? { value as? Left }
    var right: Right? { value as? Right }
}

let stuff = Stuff<Int, String>(value: ...)
assert((stuff.left == nil) != (stuff.right == nil), "Easy, right?")

let stuff = Stuff<Int, Int>(value: ...)
assert((stuff.left == nil) != (stuff.right == nil), "Oh, well...")

```

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 3, 2020, 6:34pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/93 "2020-06-03T18:34:56Z")

</div>

Yes, you're absolutely right. I was analyzing it syntactically and not thinking about the semantics.

---

<div class="post-metadata">

**Author:** ![dwaite](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dwaite/32/1200_2.png) [@dwaite](https://forums.swift.org/u/dwaite)\
**Post date:** [June 3, 2020, 6:55pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/94 "2020-06-03T18:55:44Z")

</div>

> [@John\_McCall](#):
>
> m starting to lean towards providing an `Either` in the library. Defining a real `enum` would usually be the better choice for an API, just like defining a real `struct` is usually better than using a tuple, but it's very convenient in implementations to have a type at hand with the right conformances and so on. The downsides of the type (just two cases, meaningless `first` / `second` labels) probably provide the right push towards real `enum` s.

In my opinion, tuples provide significantly more value than an Either struct would.

In addition to the common problems with tuples that Either would need new or breaking API when you move to a named type, Either would not have the option to provide semantic naming to the individual values of a particular usage.

Tuples do not provide encapsulation or association of logic - I cannot add methods to my (first: String, second: String) tuple like I can a struct. Either on the other hand would provide a mechanism for extensions to be used to attempt to carry forward the use of the Either type to library and application specific use cases.

In this way, I am concerned that the little bit of benefit of ease of use with either-vs-enum (in that it fixes a very narrow need of reducing typing when you quickly need a two option tagged union) encourages significantly more accumulation of tech debt in the resulting library than tuples-vs-structures as a comparative feature relationship.

---

<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, 8:41am UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/95 "2020-06-04T08:41:19Z")

</div>

> [@dwaite](#):
>
> In my opinion, tuples provide significantly more value than an Either struct would.

I’m assuming you are talking about Union Tuples - not regular ones.

> [@dwaite](#):
>
> breaking API when you move to a named type

I don’t think it would. Up-thread there has been a lot of [discussion about an OneOf type](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/80). Or how [multiple such types](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/91) (OneOf2, OneOf3...) could be added. I think the “multiple such types” post will give you an ideas of how we could migrate to a variadic OneOf. To sum it up, we would just deprecate Either and encourage the use of OneOf in its place. So if you’re concerned that Either will limit our future options, you shouldn’t.

> [@dwaite](#):
>
> Either would not have the option to provide semantic naming to the individual values of a particular usage.

Compiler magic to convert the expression:

```
typealias MyOneOf 
    = (foo: Foo | bar: Bar)

```

Could be converted to:

```
typealias MyOneOf(first|second|) 
    = OneOf<Foo, Bar>

```

That would be similar to another post that proposes [baking the closure labels into the identifier](https://forums.swift.org/t/include-argument-labels-in-identifiers/35367). That though is a future proposal altogether, that requires to be built one top of OneOf. There has also been talk of a “native” Union Tuple type, that will have custom compiler support. Nonetheless, that type is not acceptable to the Core Team, as they are [hardly keen on the idea of an OneOf](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/57) a type that is currently unimplementable as it requires advanced variadic genetics - correct me if I’ve misinterpreted. All in all, I would appreciate ideas that are applicable to the proposal of adding an Either like type. Lastly, I’d like to say that I don’t see a Union Type built into the compiler as a reasonable option, because it would further complicate the compiler and because there has been talk of even replacing Tuples with a normal type.

---

<div class="post-metadata">

**Author:** ![dwaite](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dwaite/32/1200_2.png) [@dwaite](https://forums.swift.org/u/dwaite)\
**Post date:** [June 4, 2020, 10:49am UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/96 "2020-06-04T10:49:13Z")

</div>

> [@filip-sakel](#):
>
> I’m assuming you are talking about Union Tuples - not regular ones.

I don’t believe union tuple is a common term.

I’m talking about the comparison between tuples and structs, vs either/anyof and enum.

The tuple (Double, Double) isn’t nearly as useful as a labeled (x:,y:), (r:, angle:), (width:, height:), etc. Either\<String, Int\> fails to allow for capturing what the semantics actually are - a string or int of what? When is the value one vs the other?

A tuple has clear limitations where it does not support encapsulation or polymorphism - you cannot have a tuple implement a protocol or add additional methods. You can do both of these with an Either type. This creates tension in that people can leverage an either/anyof type long after they should have moved to enum (perhaps because moving from either to enum is a breaking change). Examples of changes might be adding properties to give ‘friendly names’ to left/right, implementing protocols like Comparable, etc.

---

<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.

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [June 4, 2020, 2:48pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/98 "2020-06-04T14:48:17Z")

</div>

> [@filip-sakel](#):
>
> 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.

One important thing to keep in mind is that there is really no adding something to the standard library "for now". If something is added to the standard library, then it will be there for **a very long time** unless the Swift team is willing to break source and/or binary-compatibility to remove it.

Thus, additions to the standard library should meet a very high bar, and any such proposal should explain why it is critical that it be added **now** instead of focusing those efforts on building up the lower-level foundations of the language like variadic generics and constructing some way of expressing variadic cases so that something better could be provided, since—by your own post above—"`Either` is not the ideal type".

---

<div class="post-metadata">

**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\
**Post date:** [June 4, 2020, 2:54pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/99 "2020-06-04T14:54:33Z")

</div>

> [@allevato](#):
>
> One important thing to keep in mind is that there is really no adding something to the standard library "for now". If something is added to the standard library, then it will be there for **a very long time** unless the Swift team is willing to break source and/or binary-compatibility to remove it.

This is why I am opposed to introducing `Either` and why I think it is appropriate to discuss things like structural sum types in this thread.

---

<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, 3:50pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/100 "2020-06-04T15:50:12Z")

</div>

> [@allevato](#):
>
> instead of focusing those efforts on building up the lower-level foundations of the language like variadic generics and constructing some way of expressing variadic cases so that something better could be provided, since—by your own post above—" `Either` is not the ideal type".

First of all, I’d like to address the part regarding focusing our efforts on variadic generics. I think everyone wants variadic generics, especially me. I’ve been working with function builders and without variadic generics some parts are really mess. But I hate to see, that [discussion about variadic generics](https://forums.swift.org/t/variadic-generics-discussion/2817) has been going on for years, yet still to this date there’s no such feature. Not to mention that an OneOf type would require probably an advanced Variadics feature, as repetition of an element - OneOf\<Foo, Foo\> - should not be allowed.

What has been presented in this thread are real problems - in my previous post I think I mentioned some. So, seeing function builders, the standard library and other projects result to custom types and more repetitive code - that in most cases are just boilerplate - I though that a sensible direction would be a standardized Either type. And many counter-proposals I don’t see a viable alternative. What Either offers is a great set of features - custom conformance, a standardized type etc.

Yes I still think Either isn’t ideal overall, but it’s best for now, where there is a need for such a type. Furthermore, if a new Variadic type comes along and renders the use of a two-case Either type useless, it could slowly be deprecated and removed.

To sum up, there are problems that require an Either like type, whether it’ll be named Either or OneOf doesn’t matter, what matters is that those problems be solved. Once an OneOf comes along, which will most likely take a while, Either will have already helped in a lot of situations and eliminated a lot of boilerplate.

[Previous page](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972.md?page=4)

[Next page](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972.md?page=6)