# 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:** 2

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [May 29, 2020, 12:38pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/21 "2020-05-29T12:38:52Z")

</div>

> [@Tino](#):
>
> but for whatever reason, this feature is on the list of commonly rejected changes ☹

The commonly rejected change, as I understand it, is specifically about `union`-esque types (logical OR), which is slightly different from anonymous sum types (closer to logical XOR if you want to extend that analogy). Indeed, the note explaining why it won’t be accepted says that it is “something the type system cannot and should not support,” but the type system clearly can (and should!) support anonymous sum types—they are just `enum`s with less characters.

---

<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:** [May 29, 2020, 12:55pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/22 "2020-05-29T12:55:16Z")

</div>

> [@filip-sakel](#):
>
> Furthermore, @anandabits offers another compelling reason why the proposed type would be a worthy addition.

To be clear, I do not think an `Either` type in the standard library is the right direction. I want language support for anonymous sum types.

As @Jumhyn explained, anonymous sum types are much different than union types. To my knowledge, anonymous sum types have not yet received serious discussion and consideration by the community.

---

<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:** [May 29, 2020, 1:05pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/23 "2020-05-29T13:05:48Z")

</div>

I'm not sure, and it's easy to confuse union and sum types…

The [union type](https://en.wikipedia.org/wiki/Union_type) from, for example, C++ does not seem like a good fit for Swift to me, but a "tagged union with hidden tag" (see [Ceylon](https://ceylon-lang.org/documentation/1.3/tour/types) for an example) is extremely powerful: The use case for [sealed protocols](https://forums.swift.org/t/sealed-protocols/19118/1) could not only be modelled with tagged unions — imho it's actually the better way to do so.

Enums are quite different, and I have no idea how exactly anonymous enums should work.

---

<div class="post-metadata">

**Author:** ![ExFalsoQuodlibet](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@ExFalsoQuodlibet](https://forums.swift.org/u/ExFalsoQuodlibet)\
**Post date:** [May 29, 2020, 2:13pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/24 "2020-05-29T14:13:30Z")

</div>

> [@filip-sakel](#):
>
> the seemingly unimportant `Either` type

The `Either<A, B>` type is **exactly** as important as `(A, B)`, no more, no less: for example, being able to "return `A` and `B` from a function" is **exactly** as important as being able to "return `A` or `B` from a function". These are dual constructions, there's no reason to favor one over the other in terms of utility: sometimes I want to milk and cookies, other times I want either milk or cookies.

That being said, to me the ideal case here would be to have anonymous sum types, like `(A | B)`, that could be inspected by index, with `.0` and `.1`: and of course, the importance of `(A | B)` is **exactly** the same as `(A, B)`.

EDIT: I might have come out a tad too aggressive here. That's not my intention, I understand that not many are used to think about things in `Either` terms. I just want to highlight the fact that there's an objective dualism here between the constructions, that maps to a dualism of meanings.

---

<div class="post-metadata">

**Author:** ![Max\_Desiatov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/max_desiatov/32/20654_2.png) [@Max\_Desiatov](https://forums.swift.org/u/Max_Desiatov)\
**Post date:** [May 29, 2020, 2:46pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/25 "2020-05-29T14:46:23Z")

</div>

> [@ExFalsoQuodlibet](#):
>
> not many are used to think about things in `Either` terms

We could hope that plenty of people are used to think about things in `Result` terms, which is basically `typealias Result<A> = Either<A, Error>` 🙂

---

<div class="post-metadata">

**Author:** ![rumnat](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rumnat/32/7823_2.png) [@rumnat](https://forums.swift.org/u/rumnat)\
**Post date:** [May 29, 2020, 3:09pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/26 "2020-05-29T15:09:15Z")

</div>

small thing but can come in handy to have a clear contract that you always have one of two values

---

<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:** [May 29, 2020, 3:21pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/27 "2020-05-29T15:21:46Z")

</div>

> [@anandabits](#):
>
> To be clear, I do not think an `Either` type in the standard library is the right direction. I want language support for anonymous sum types.

Sorry, I misunderstood.

> [@anandabits](#):
>
> As @Jumhyn explained, anonymous sum types are much different than union types. To my knowledge, anonymous sum types have not yet received serious discussion and consideration by the community.

Would you elaborate on what exactly you are proposing here. Does the following seem like what you are looking for?

```swift
let a: A | B | C = A()
// Equivalent to:
let oneOf: OneOf<A, B, C> = .choosing(A())

```

> **Note:**
>
> In the above I just think that `OneOf` should be there as `Optional` is the actual type behind an expression such as this: `func foo() -> Bar?` (== `Optional<Bar>`).

### Sum Types Direction

In the above example of in what I assume you mean by sum types, we could do something like:

```swift
let foo: Any = oneOf.value // A value of A, B or C

```

or:

```swift
let bar: A? = oneOf.value

```

or:

```swift
let bar: A? = oneOf[A.self]

```

to access the value. We could also do:

```swift
oneOf.0 // A?
oneOf.1 // B?
oneOf.2 // C?

```

Another alternative (same as the above with subscript syntax):

```swift
oneOf[0] // A?
oneOf[1] // B?
oneOf[2] // C?

```

IMHO, the following should be chosen if we choose to go down this path:

```swift
let foo: Any = oneOf.value // A value of A, B or C
let bar: A? = oneOf.value

oneOf[0] // A?
oneOf[1] // B?
oneOf[2] // C?

```

Does any of the above feel appropriate?

#### Common control flow structures

1. Switch statements:

2. If/Guard statements:

---

<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:** [May 29, 2020, 3:27pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/28 "2020-05-29T15:27:10Z")

</div>

> [@ExFalsoQuodlibet](#):
>
> I understand that not many are used to think about things in `Either` terms.

I would expect the opposite to be true—anyone who uses `enum`s with associated values in Swift is very used to thinking in `Either` terms, even if they don't call it that.

The key difference is that use-case-specific `enum`s provide valuable information in their labels, and possibly in their constraints; as @Max_Desiatov points out, `Result` is essentially `Either` where one of the values is constrained by `Error`, and its labels `success` and `failure` make their usage clear vs. more generic terms.

> [@ExFalsoQuodlibet](#):
>
> The `Either<A, B>` type is **exactly** as important as `(A, B)` , no more, no less
> 
> the importance of `(A | B)` is **exactly** the same as `(A, B)`

This feels like a bit of a contradiction. What some folks, including myself, are claiming is that that `Either<A, B>` specifically **is** less important than `(A, B)` because it only considers the 2-element case, whereas both `(A, B)` and a hypothetical `(A | B)` are generalizable to _N_ elements. It would be akin to having `Pair<A, B>` in the standard library.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [May 29, 2020, 3:42pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/29 "2020-05-29T15:42:05Z")

</div>

> [@filip-sakel](#):
>
> The model of `Either<AlphaComponent, NoAlpha>` represents the enum [`CGImageAlphaInfo`](https://developer.apple.com/documentation/coregraphics/cgimagealphainfo), where due to the absence of an `Either` type, both information for decoding when there is no alpha channel and when there is an alpha channel, is cramped together instead of being neatly separated into different enums. I hope I cleared up some of the confusion!

Core Graphics isn't a Swift library, and even if it were, I'm not seeing how `CGImageAlphaInfo` lends itself to an `Either` type. How exactly would you redesign the type to fulfill its current role?

> [@filip-sakel](#):
>
> It just seems like `Either` holds great potential especially with compiler 'magic' that could be added in the future.

You'll have to offer at least some specifics: great potential for what? with what compiler magic? I'm not seeing a clear use case outlined here.

> [@filip-sakel](#):
>
> Furthermore, @anandabits offers another compelling reason why the proposed type would be a worthy addition.

As @anandabits has written, he's arguing for anonymous sum types.

---

<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:** [May 29, 2020, 4:22pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/30 "2020-05-29T16:22:04Z")

</div>

> [@xwu](#):
>
> > [@filip-sakel](#):
> >
> > It just seems like `Either` holds great potential especially with compiler 'magic' that could be added in the future.
> 
> You'll have to offer at least some specifics: great potential for what? with what compiler magic? I'm not seeing a clear use case outlined here.

#### Omission of `Either` 'initialiser'

Firstly, I think we should consider something similar to `Optional`:

```swift
func foo() -> Either<Bar, Baz> {
    myCondition ? Bar() : Baz() // ✅ 
    // Equivalent to:
    myCondition ? .choosing(Bar()) : .choosing(Baz())
}

```

> **choosing(\_:)**
>
> ```swift
> static func choosing(_ value: First) -> Self { .first(value) }
> static func choosing(_ value: Second) -> Self { .second(value) }
> 
> ```

This would be a great way for a hypothetical type such as `Time`:

```swift
enum TimeDescriptor {
    case aLongTime, aReallyLongTime, aLittleTime
}
typealias Time = Either<Double, TimeDescriptor>

wait(for: .aLongTime)
wait(for: 0.3)

```

Or for something like `Font Weight` (I'm not going to bother you with the implementation):

```swift
setFontWeight(to: .bold)
setFontWeight(to: 600)
setFontWeight(to: myCustomDoubleValue)

```

#### Automatic Protocol Conformance

Another more advanced feature could be automatically conforming `Either` to protocols - or classes if both the first and second type are classes - that both types conform to. So that this would be possible:

```swift
protocol Foo {
    func foo() { ... }
}
struct Bar: Foo {}
struct Baz: Foo {}

let myEitherValue: Either<Bar, Baz> = ...

myEitherValue.foo()

```

So, in the example above, with time, if both Double and TimeDescriptor conformed to hypothetical protocol `Operatable` - which would provide basic operations, such as +, -, /, \*- we could write:

```swift
wait(for: .aLongTime + 0.5)

```

---

<div class="post-metadata">

**Author:** ![rvsrvs](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rvsrvs/32/5270_2.png) [@rvsrvs](https://forums.swift.org/u/rvsrvs)\
**Post date:** [May 29, 2020, 4:49pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/31 "2020-05-29T16:49:37Z")

</div>

The pointfree guys discussed this idea in [Episode #51: Structs 🤝 Enums](https://www.pointfree.co/episodes/ep51-structs-enums) back in March '19. They even proposed some syntax that looked like tuples with `|` replacing the `,` between fields. That's a subscriber-only link, I'm just highlighting it to say that it has in fact received discussion in some corners of the community. I'm a big +1 on the entire idea as a result that discussion.

---

<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:** [May 29, 2020, 5:01pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/32 "2020-05-29T17:01:14Z")

</div>

> [@rvsrvs](#):
>
> The pointfree guys discussed this idea in [Episode #51: Structs 🤝 Enums](https://www.pointfree.co/episodes/ep51-structs-enums) back in March '19. They even proposed some syntax that looked like tuples with `|` replacing the `,` between fields. That's a subscriber-only link, I'm just highlighting it to say that it has in fact received discussion in some corners of the community. I'm a big +1 on the entire idea as a result that discussion.

Thanks for sharing that link here, I was speaking about SE specifically and not the broader community. @stephencelis has been the most vocal advocate of putting sum types on equal footing as sum types in the language. Point Free has several ideas in this direction, all of which are great!

---

<div class="post-metadata">

**Author:** ![ExFalsoQuodlibet](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@ExFalsoQuodlibet](https://forums.swift.org/u/ExFalsoQuodlibet)\
**Post date:** [May 29, 2020, 5:19pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/33 "2020-05-29T17:19:10Z")

</div>

> [@allevato](#):
>
> I would expect the opposite to be true—anyone who uses `enum` s with associated values in Swift is very used to thinking in `Either` terms, even if they don't call it that.
> 
> The key difference is that use-case-specific `enum` s provide valuable information in their labels, and possibly in their constraints; as @Max_Desiatov points out, `Result` is essentially `Either` where one of the values is constrained by `Error` , and its labels `success` and `failure` make their usage clear vs. more generic terms.

I agree. What I meant is that people might be less inclined to think in completely generic terms about a value that's either something or something else, without domain-specific names attached to cases.

> [@allevato](#):
>
> This feels like a bit of a contradiction. What some folks, including myself, are claiming is that that `Either<A, B>` specifically **is** less important than `(A, B)` because it only considers the 2-element case, whereas both `(A, B)` and a hypothetical `(A | B)` are generalizable to _N_ elements. It would be akin to having `Pair<A, B>` in the standard library.

I agree, 100%. A generalizable (\_ | ...) syntax would be great. And yes, `Either<A, B>` is definitely less important than a generic n-value tuple (but is exactly as important as the specific 2-tuple).

Unfortunately, in the [commonly rejected changes](https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md) it is stated that anonymous union types are not going to be ever supported: I'm not completely sure how to interpret that paragraph (or if the core team changed their mind here), but if there's was no way to ever get `(A | B)`, I'd rather have at least a `Either<A, B>`, and possibly a bunch of them with different arity, in the standard library.

Anyway, my more general point is that sum types are as important as product types, and I would expect every feature and construction available to the latter to be also, dually, present for the former.

---

<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:** [May 29, 2020, 5:24pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/34 "2020-05-29T17:24:06Z")

</div>

`(A | B)` is just strawman syntax used in this thread for what could be a variety of concepts. A true "anonymous union" type would be one that allows the user to assign a value of either type `A` or `B` to it without explicit conversion and would likely also support the common set of properties/methods from both of those types, again without any kind of explicit casting or qualification. I _believe_ that's what that section of the document is referring to.

An anonymous enum expressed using something like numbered cases analogous to unlabeled tuples (`case .0(let foo): case .1(let bar)`) and requires explicit pattern matching to extract the values would not be the same thing.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [May 29, 2020, 5:33pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/35 "2020-05-29T17:33:49Z")

</div>

> [@filip-sakel](#):
>
> Omission of `Either` 'initialiser'

> [@filip-sakel](#):
>
> Automatic Protocol Conformance

You're showing me features that can be added to `Either`.

However, my question is, what is the "great potential" unlocked by this type? In other words, I'm asking _why use_ (not _how to use_) `Either` in the first place: in what specific scenarios would this type represent the best solution?

> [@filip-sakel](#):
>
> ```swift
> wait(for: .aLongTime)
> wait(for: 0.3)
> 
> ```

Such a design requires users to wrap the argument in an `Either` type before passing them to a function named `wait(for:)`, which either requires the compiler to optimize the wrapping and unwrapping away or imposes a runtime performance cost. Instead, we can already allow users just to pass the values themselves to one of two suitable overloads, which is a superior way to design this API, being more straightforward to use and also more straightforward to compile. In this scenario, `Either` would be an attractive nuisance rather than a feature.

> [@filip-sakel](#):
>
> Or for something like `Font Weight` (I'm not going to bother you with the implementation):

This use case seems to call for a garden variety custom enum `FontWeight { case extraLight, light, regular, bold, extraBold, custom(Int) }`. I don't see how `Either` would yield a superior result here either.

If you have a reason for preferring `Either` in these examples, I'd love to explore the specifics of _why_. Again, it's important to delve into fully fleshed out use cases; _do_ bother with implementations.

> [@filip-sakel](#):
>
> So, in the example above, with time, if both Double and TimeDescriptor conformed to hypothetical protocol `Operatable` - which would provide basic operations, such as +, -, /, \*- we could write:

This isn't theoretically sound. A length can be added to a length, and a time interval can be added to a time interval, but that doesn't mean that a length can be added to a time interval, or a dollar amount to a weight. For the same reason, protocols with associated types cannot self-conform. In the case of such a protocol `P`, what you describe would cause `Either<P, Never>` to be equivalent to a self-conforming protocol existential 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:** [May 29, 2020, 5:50pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/36 "2020-05-29T17:50:35Z")

</div>

> [@xwu](#):
>
> I'm asking _why use_ (not _how to use_ ) `Either` in the first place: in what specific scenarios would this type represent the best solution?

The need for unions can arise naturally when zipping, depending on the structure of the type that is zipped. As with the tuples produced by the zip that we already have, a further transformation is often applied. I work on a library that currently uses `AnyOfN` types in this circumstance. I would greatly prefer not to need these types. I would even more greatly prefer to be able to write the operators that produce these types in a variadic way. That is unlikely to be possible with user-defined nominal types even if we have variadic generics in the language.

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [May 29, 2020, 5:53pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/37 "2020-05-29T17:53:38Z")

</div>

As a (semi-)aside, the "union type" on the commonly rejected changes list is about a type with _implicit conversions,_ which is a little different from the anonymous-but-explicit enum/union/sum types advocated by Pointfree and others. I wish I could find a citation for how they'd complicate the type system, but I can't, although there's a little discussion way back in [an early thread about Result and Either](https://forums.swift.org/t/proposal-an-either-type-in-the-stl/372/).

[TypeScript's union types](https://www.typescriptlang.org/docs/handbook/advanced-types.html#union-types) allow accessing members common to all parts of the union. Swift is unlikely to support that because the low-level calling conventions for different types don't match up, and besides, Swift doesn't consider two methods with the same name to be "basically the same operation" unless they're on types conforming to the same protocol.

[Ceylon's union types](https://ceylon-lang.org/documentation/1.0/tour/types/#union_types) don't allow accessing any members ad hoc, but _do_ allow converting to a supertype of all members. (That is, `UIScrollView | UITableView` can be converted to `UIView`.) This can still have strange behavior when interacting with Swift's generics: if I have an `[Int] | Set<Int>` value, and I pass it to a function that takes any Collection via generic parameter and returns an index, what's the type of the result? Or is that just not allowed?

Even if your anonymous enum/union/sum type requires explicit deconstruction (i.e. "you have to pattern-match it to do anything"), there's still the question of whether you'd allow implicit conversions _to_ the type. Even that adds additional complication in Swift's type system, though, which allows inferring types across an entire expression. While Swift's type checker has gotten a _lot_ better over the last five years, implicit conversions are still one of the ways to make it do exponentially more work if we're not careful how it's defined.

There may also be additional complications I haven't thought of; maybe one of the type system folks will know what John and Chris were referring to in those early comments about "massively complicated the type system". But I'm pretty confident that the explicit form where you say `.0(x)` and match against `case .0(let value)` don't hit any of those problems. (Whether or not they're worth it is a different question.)

---

<div class="post-metadata">

**Author:** ![ExFalsoQuodlibet](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@ExFalsoQuodlibet](https://forums.swift.org/u/ExFalsoQuodlibet)\
**Post date:** [May 30, 2020, 7:58am UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/38 "2020-05-30T07:58:17Z")

</div>

> [@allevato](#):
>
> An anonymous enum expressed using something like numbered cases analogous to unlabeled tuples ( `case .0(let foo): case .1(let bar)` ) and requires explicit pattern matching to extract the values would not be the same thing.

I agree. What I'd like to see is an anonymous sum (coproduct) type without implicit conversion, that's dual to tuples. I personally don't really care about (non-tagged) union types with implicit conversion a là Typescript or Scala 3: but I do care about the ability of using the same syntax and power of tuples (including optional labels) but with "either" semantics.

> [@jrose](#):
>
> the "union type" on the commonly rejected changes list is about a type with _implicit conversions_

Thanks a lot for this clarification.

> [@jrose](#):
>
> Whether or not they're worth it is a different question.

They're worth exactly the same as tuples are worth today in Swift, that is, a lot. This is one of those cases where there's really no point in showing examples, because we already have tuples, and everything that can be said for a tuple could be said for an anonymous either.

In my personal experience, one of the main applications is for sequences and streams, in which each element can be one of a number of options: being able to operate generically on such sequence, by folding it or partitioning it, for example, is of great value.

And in general, the idea of generically being able to return from a function A or B (or C...) has exactly the same value as being able to return A and B (and C...).

As Pointfree points out really, really well, Swift doesn't take advantage enough (if at all) of the duality between product and sum types, but there's not reason to favor one over the other, and similar (but dual) properties and constructions should be available for both.

The following table shows a few of those:

| | Products | Sums |
| --- | --- | --- |
| Nominal constructions | Yes, `struct` | Yes, `enum` |
| Field access on nominal constructions | Yes, with properties | No |
| Destructuring of nominal constructions | No | Yes, with `case` |
| Anonymous (optionally labeled) constructions | Yes, with tuples | No |
| Field access on anonymous constructions | Yes, with index or label | No |
| Destructuring of anonymous constructions | Yes | No |

There are 5 spots here with a "No" inside, that in my opinion should all be filled with a "Yes", eventually: 2 of these spots would be set to "Yes" with the kind of "anonymous either" we're talking about here.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [May 30, 2020, 12:55pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/39 "2020-05-30T12:55:36Z")

</div>

> [@ExFalsoQuodlibet](#):
>
> They're worth exactly the same as tuples are worth today in Swift, that is, a lot.

[citation needed]

> [@ExFalsoQuodlibet](#):
>
> This is one of those cases where there's really no point in showing examples,

Hard disagree.

> [@ExFalsoQuodlibet](#):
>
> because we already have tuples, and everything that can be said for a tuple could be said for an anonymous either.

How about,

“When a function returns a tuple, the caller can directly access and use members of the tuple because they have known types.”

?

That cannot be said about a sum type, because by definition—in fact the main feature—of a sum type is that it could hold any one of several possible types.

That is a hands-on, real-world difference. between sums and tuples. They are used for different things, in different situations.

Yes, mathematically they are structural duals. But we are not dealing with abstract mathematics here. We are dealing with an actual programming language, created, maintained, and used worldwide by real people.

The question at hand is, “Do the benefits to the users of the language from adding this feature, outweigh the costs to the creators, maintainers, and yes, the users themselves?”

In order to answer that, we need at least a general idea of what the benefits are to users.

Helping people understand those benefits is the purpose of examples.

Examples are necessary.

---

<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:** [May 30, 2020, 1:47pm UTC](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/40 "2020-05-30T13:47:56Z")

</div>

> [@ExFalsoQuodlibet](#):
>
> There are 5 spots here with a "No" inside, that in my opinion should all be filled with a "Yes", eventually: 2 of these spots would be set to "Yes" with the kind of "anonymous either" we're talking about here.

Thanks for posting this table! It could be extended with an entry showing the `CasePath` dual of `KeyPath`. That is also a fundamental abstraction related to sum types that should have a place in the language and standard library. I think the popularity of The Composable Architecture demonstrates the utility and need for this very well.

> [@Nevin](#):
>
> When a function returns a tuple, the caller can directly access and use members of the tuple because they have known types.”
> 
> ?
> 
> That cannot be said about a sum type, because by definition—in fact the main feature—of a sum type is that it could hold any one of several possible types.

Direct access is not the only thing that matters:

```swift
switch someFunctionReturningLabeledSum() {
case .firstLabel(let value):
...
}

switch someFunctionReturningUnlabeledSum() {
case .0(let value):
...
}

```

This may not be direct use of the components, but it is direct use of the function result.

There is no more reason to require the function to declare a nominal enum than there is to require functions returning a product type to declare a nominal struct. As I mentioned previously, there are times where generic code _is not able to add any value in a name_. This is common when composing values. It is why I have had to declare a family of `AnyOfN` types. It is a pretty clear gap in the language IMO.

> [@Nevin](#):
>
> In order to answer that, we need at least a general idea of what the benefits are to users.
> 
> Helping people understand those benefits is the purpose of examples.
> 
> Examples are necessary.

Anonymous sums integrated with variadic generics should enable merging of any number of heterogenous streams of values with a single generic implementation. It should also enable writing a single generic implementation that can fold such a stream into a homogenous stream. Does that example help you to see the utility in real world programming?

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

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