[proposal] Either in the Swift Standard Library

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

Now that I think about it, `fold` is not a great name for the cata on Either, [too bad `either is taken!]. Rust calls it `unwrap_or`, so maybe `unwrapLeft`, `unwrap`, etc? Also, we’ve found some use for partial projections in JSON parsing libraries, so it might be worth looking into adding them to the proposal.

extension Either {
  var fromLeft : LeftValue? {
    switch self {
    case let .Left(l):
      return l
    default:
      return nil
    }
  }

  var fromRight : RightValue? {
    switch self {
    case let .Right(r):
      return r
    default:
      return nil
    }
  }
}

···

On Jan 9, 2016, at 2:19 PM, Developer <devteam.codafi@gmail.com> wrote:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

···

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

As this thread is already quite huge, and discussion could go on forever, maybe you don't mind a crosspost:
I really don't think "Either" belongs to the standard library, but I also think it is bad to have a thousand nearly identical implementations of it.
So, what is the right place for Either?
My answer to that question is written in another thread:
http://thread.gmane.org/gmane.comp.lang.swift.evolution/4640/focus=4667

There are no signs anyone at Apple would support a standard library for functional programming, but maybe we as a community are strong enough to establish it on our own.

David already created something (https://github.com/swift-breeze\) that could act as a starting point.
I have no idea if this will work out well, but I'm planning to push aside vanity and contribute to a project that is neither my own nor lures with the fame associated with core Swift itself.

So, why not simply push back discussion and start coding & committing? ;-)

Tino

Just added a section of motivating examples to the Either proposal. Ping
me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

Your motivating examples (including all the projects you linked except "Any
many more") overwhelmingly use the Either (or similar type) to represent
success/failure. I'm not sure there's a single example where the names Left
and Right actually make sense in the problem domain. I'm not 100% sure
about func alternate in Madness/Alternation.swift. It definitely uses
Left/Right to mean Failure/Result, but I couldn't tell if it also uses them
as something else. Which makes those names all the more maddening.

I checked my company's largest Scala project, which is over 300,000 lines.
We use Scala's Try/Success/Failure in dozens of places. We use
Either/Left/Right once, in a thrown-together report-generating script,
which would probably have been written in awk or perl if it didn't need to
read binary log files. (The ability of IntelliJ to reliably find all uses
of a class or method is not to be underestimated. Hint hint, team Xcode.)

I think a Result/Success/Failure type is warranted, but I'm very skeptical
about generic Either/Left/Right.

I was reading the proposal and I have to admit I do like Either and have used it extensively in Scala for normal exceptions (business validations) leaving exceptions to … exceptional circumstances. If I went back I think I could get rid of quite a bit of stuff if I had put more thought into it.

When it comes to validations though I was wondering how you saw it coming together:

i.e. you have a set of validations that you run (independent validations) where after you finished if any of them has a validation you just want a list of business exceptions.

The other scenario I could see is dependent validations where certain validations you want to skip because a validation that it was dependent on failed - i.e. you don’t want to be flooded with other validations which occur solely due to an earlier failed validation. (i.e. concise execution of a list of validations or something like that).

···

On 2016-01-21, at 10:17:34, Developer via swift-evolution <swift-evolution@swift.org> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hello all,

I’m going to try and round up a summary of arguments for and against this proposal and my response to them, because I think there is a clear sense in everybody’s mind what Either entails, but that sense differs widely depending on individual interactions with the parts of the proposal. I take full responsibility for the rhetoric and the style of debate that has been going on for the past ~24 hours. It was borderline unprofessional the way this was going and I want to apologize now to those involved for being so very unclear in my reasoning and my rhetoric as to stir up a senseless debate about points we essentially agreed on beforehand. As such, I’ve made some revisions to the proposal, I request that you all please re-read it (at https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md\) before we try again so we can refocus this debate on more productive avenues of discourse.

Throughout this reply I’ve made heavy use of quotes from other replies. Those will appear in purple. Quotes from the proposal will appear in blue.

The type “Either” that we describe in the proposal is a placeholder. I feel that must be emphasized, because there have been arguments about the name. We specifically mention this in the proposal:

The Swift Standard Library will be updated to include a left-biased sum type we have called Either - though other names may be appropriate depending on how the type is implemented.

What we are requesting is a finite-case, here precisely two-case, type that represents two disjoint possibilities. As noted before, this type is often called Result by Swift framework authors and notably the programming language Rust which uses it in place of an exception handling mechanism.

Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain.

There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` has no intuitive meaning whatsoever. It says absolutely nothing about what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result<T> you actually want to define your own enum so you can attach meaning to the value.

You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result<T,E> type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).

We recognize that Result conveys a particular semantics that encourage this type to cross over into the error-handling domain. As noted in the proposal, we don’t want to emphasize this case because a version of this proposal was already rejected for overlapping too heavily with throws. If the community feels that the proposal deserves to be rewritten in a way that re-emphasizes this case and makes that point then I am up for it. But, I request that this not be used as an argument to reduce the genericity of the type - which is to say I don’t wish to see a Result<T> or a Result<T, E : ErrorType> because they reduce the power of the original proposal.

When I use the term genericity, I am not arguing for the naming scheme of the Either we have, I’m arguing for the structure to be kept around as-is. My biggest fear is that a Result with one lobe and an Error is going to be merged rather than the full proposal because this type and the discussion of it outside of here can become too absorbed in the error-handling case. I do not wish to lose the structure of the type we have now, because that structure is precisely what a future Swift could generalize and abstract upon. The name, however, is up for grabs. We offer a list of alternatives at the end of the proposal, if you have any more to suggest please reply to me here and I’ll see about adding them.

At the same time, it has been brought up that Either conveys no immediate useful information. At the time of writing this proposal, we do not believe that to be the case, but we recognize that by naming this Result we can reach a wider audience. At the end of the day the proposal is about merging in a 2-case sum type. We chose Either not because we wanted to see it merged, but precisely because it was so meaning-agnostic. It’s our lorem-ipsum. For those that think we’re trying to merge a Haskell-ism, I can say with complete confidence that no part of TypeLift intended that in the original proposal. Whatever bad taste Haskell may have left in anybody’s mouth, the Either in our proposal is a placeholder for a name to be decided upon by the community. I felt that this was clear from the line

though other names may be appropriate depending on how the type is implemented.

and

In addition, the name `Either` does not lend much to the imagination,
and the use of `Left` and `Right` have the potential to cause confusion to
novices expecting a `Result<T>`

in the original proposal, but I was wrong. I have updated the draft accordingly.

Besides, even if the type in the proposal were to be merged right this very second, “meaningless" names and all, a domain-specific Result type could easily be recovered from it. The same is not true of a type that is immediately domain-specific like the reduced-generic forms of Result. To translate that into the language of Result using Either as a template: If a Result<T, E> were not merged, then it could not be recovered from Result<T> in any meaningful manner. However, a constrained Result<T, E : ErrorType> can be recovered from the fully generic type in the proposal.

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names. Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?

This is in line with the goals of the proposal and I would certainly support this renaming if it serves the community’s best interest. You all are, by now, aware of my qualms with the name, but I’m not one to dwell on these things when we’ve made it clear in the proposal that the type can go by many names. It’s the structure of a sum that we’re after, and we’re willing to take it how it comes - but contingent on the shape of the type not differing from the proposal as written. I request that if the name Result be brought up again, that it come with the specific number and kind of parameters involved so we can nail down the shape being discussed.

The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples. However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements. Your Either type has neither of these features.

Contrary to the impression the other discussion has made, nowhere in the proposal do we wish to augment the type system. If this is done correctly, the type in the proposal should be a ~40-line addition to the standard library, it should not wind up as a full-blown language change. We are not advocating for an n-element sum type, nor are we arguing for a structural typing scheme that would put variadic sums in the language because we recognize that solution is untenable. We are, however, advocating for the inclusion of a 2-case sum type we happen to call Either in writing.

The type system already supports N-ary “either” types. We call them enums.

This is another example of exactly why Either is terrible in practice. I understand that from a type algebra point of view this is perfectly reasonable and clean and that a 2-way sum is all that is necessary because larger sums are easily created by construction. Type theory-wise it’s lovely.

Because this is a non-goal of the type. The sum as presented in the proposal does not attempt to take the place of enums, nor does it make any bones about being a finite entity. We are specifically emphasizing the two-element case. Any other arguments that pertain to its inclusion as a feature of the type system should start at the last site of discussion and probably terminate in a separate proposal adding that kind of scheme to the Swift language itself. We are arguing for a simple change to the standard library, nothing more.

As before, unlike `throws`, a disjoint union type can be applied in arbitrary
positions, used as a member, and easily checked for completeness
at compile time. In addition, the lack of a standard union type has
led the Swift community to create [numerous](https://github.com/search?utf8=✓&q=Either+language%3Aswift\) duplicate implementations of the
same mutually incompatible types over and over and over again. In the
interest of promoting a type that there has received clear interest by the
community, the addition to the Standard Library is necessary.

The argument is not “let’s toss out all implementations of 2-case enums in favor of this sum” it’s “very often, when you’ve got a two-case enum with bias, you’ve got a sum described in the proposal”. This pattern shows up in a sufficiently large number of cases that we feel that the standard library deserves to have the final say as to a community-guided implementation of this type because individual implementations seem to differ only in a few minor places like naming or generic positions.

I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.

This is another motivating factor that lines up with a major tenant of the proposal. We would not be suggesting this change to the standard library if we did not see this pattern show up in a number of large frameworks, applications, and everything in between. We offer a section of motivating examples and links that should convince you of its commonality if that is still a sticking point.

I’d say “works”, not works; the ergonomics are terrible, you are unlikely to be able to take advantage of the bias anymore, and even if we overlook all that, you still have to enforce an external convention to get mutual-interoperability at each n; otherwise, you may say Either<Either<,>,Either<,>> but I may say Either<Either<Either<,>,>,> and someone else may say Either<,Either<,Either<,>>> and someone else says Either<,Either<Either<,>,>> and so on…

This point, while valid, is also an unfortunate feature of Optionals as well, which I have argued can be viewed as an Sum with one lobe “sealed” by Top, the empty tuple. I have yet to see a use of a sum type that needs nesting like this, nor have I seen any type or type alias that attempts to use this to recover an n-ary Sum because it just doesn’t happen. If you have a disjoint set of possibilities with order greater than two, as Chris noted, Swift already offers enums. And if such a case has arisen, it needs to be refactored just as Optional<Optional<Optional<...>>> would be.

* An either-like type should be named something meaningful for the context it is used

See above.

* There are a lot of cases where an either-like type is useful, there may generalised functions that are often used on them

See proposal.

* Is defining or re-defining an either type hard?

See proposal.

* Is it too niche to be in the standard library

We don’t believe so, see proposal.

No, I take issue with the entire fundamental idea behind your proposal. You've explicitly defined this type purely by its shape, with no meaning whatsoever given to either variant, except insofar as the type is Left-biased (which only serves to be even more confusing; since there's no actual meaning assigned to Left/Right, what is the justification for adding the left-biasing?)

The rationale given for bias has been updated in the latest draft.

tl;dr

···

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.

On Jan 20, 2016, at 10:17 PM, Developer <devteam.codafi@gmail.com> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

My overwhelming concern, after having a conversation with Chris, is that implementing a Result<T> means we are strongly implying a particular semantics and use case when we could generalize and abstract for no cost but an extra generic parameter. In F#, Core.Choice can be used to build a Validation or Result monad, but the converse is impossible.

~Robert Widmann

2016/01/23 1:05、Rob Mayoff via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain. I'm not 100% sure about func alternate in Madness/Alternation.swift. It definitely uses Left/Right to mean Failure/Result, but I couldn't tell if it also uses them as something else. Which makes those names all the more maddening.

I checked my company's largest Scala project, which is over 300,000 lines. We use Scala's Try/Success/Failure in dozens of places. We use Either/Left/Right once, in a thrown-together report-generating script, which would probably have been written in awk or perl if it didn't need to read binary log files. (The ability of IntelliJ to reliably find all uses of a class or method is not to be underestimated. Hint hint, team Xcode.)

I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes, you definitely can use this Either to recover the Validation monad a la Scala. I think I have to draw up an implementation and submit it to Swiftz!

~Robert Widmann

2016/01/22 23:45、Craig Cruden <ccruden@novafore.com> のメッセージ:

···

I was reading the proposal and I have to admit I do like Either and have used it extensively in Scala for normal exceptions (business validations) leaving exceptions to … exceptional circumstances. If I went back I think I could get rid of quite a bit of stuff if I had put more thought into it.

When it comes to validations though I was wondering how you saw it coming together:

i.e. you have a set of validations that you run (independent validations) where after you finished if any of them has a validation you just want a list of business exceptions.

The other scenario I could see is dependent validations where certain validations you want to skip because a validation that it was dependent on failed - i.e. you don’t want to be flooded with other validations which occur solely due to an earlier failed validation. (i.e. concise execution of a list of validations or something like that).

On 2016-01-21, at 10:17:34, Developer via swift-evolution <swift-evolution@swift.org> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I would think that if Either is in core — and Validation is not to dependent on other functional concepts (too deeply tied to the rest of Swiftz) — and being a very core concept for any application that it would be bundled with Either in standard libraries as well. Pretty well every business application — large or small — functional or not — would benefit from a very easy /non-verbose validation mechanism.

I view Either conceptually as part of the contract that a function provides (normal validation; e.g. Person’s birth cannot be future-dated) which is expected as part of the functions process…. (and are expected and will be dealt with by whatever is calling it)…. while Exceptions are for exceptional circumstances / technical failings that may not be expected during normal operation such as a catastrophic fail (e.g. Server not found). An Either/Validation business validation would be returned in a message on the same server or to a calling service, while technical failings might do things like fail-over.

Not sure if I am expressing myself correctly.

···

On 2016-01-23, at 13:32:06, Developer <devteam.codafi@gmail.com> wrote:

Yes, you definitely can use this Either to recover the Validation monad a la Scala. I think I have to draw up an implementation and submit it to Swiftz!

~Robert Widmann

2016/01/22 23:45、Craig Cruden <ccruden@novafore.com> のメッセージ:

I was reading the proposal and I have to admit I do like Either and have used it extensively in Scala for normal exceptions (business validations) leaving exceptions to … exceptional circumstances. If I went back I think I could get rid of quite a bit of stuff if I had put more thought into it.

When it comes to validations though I was wondering how you saw it coming together:

i.e. you have a set of validations that you run (independent validations) where after you finished if any of them has a validation you just want a list of business exceptions.

The other scenario I could see is dependent validations where certain validations you want to skip because a validation that it was dependent on failed - i.e. you don’t want to be flooded with other validations which occur solely due to an earlier failed validation. (i.e. concise execution of a list of validations or something like that).

On 2016-01-21, at 10:17:34, Developer via swift-evolution <swift-evolution@swift.org> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The other minor point is that this type (TBD) may not in fact be a result of function (of which everything returned from a function is in fact a result) would be an erroneous name.

···

On 2016-01-27, at 12:09:07, Developer via swift-evolution <swift-evolution@swift.org> wrote:

Hello all,

I’m going to try and round up a summary of arguments for and against this proposal and my response to them, because I think there is a clear sense in everybody’s mind what Either entails, but that sense differs widely depending on individual interactions with the parts of the proposal. I take full responsibility for the rhetoric and the style of debate that has been going on for the past ~24 hours. It was borderline unprofessional the way this was going and I want to apologize now to those involved for being so very unclear in my reasoning and my rhetoric as to stir up a senseless debate about points we essentially agreed on beforehand. As such, I’ve made some revisions to the proposal, I request that you all please re-read it (at https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md\) before we try again so we can refocus this debate on more productive avenues of discourse.

Throughout this reply I’ve made heavy use of quotes from other replies. Those will appear in purple. Quotes from the proposal will appear in blue.

The type “Either” that we describe in the proposal is a placeholder. I feel that must be emphasized, because there have been arguments about the name. We specifically mention this in the proposal:

The Swift Standard Library will be updated to include a left-biased sum type we have called Either - though other names may be appropriate depending on how the type is implemented.

What we are requesting is a finite-case, here precisely two-case, type that represents two disjoint possibilities. As noted before, this type is often called Result by Swift framework authors and notably the programming language Rust which uses it in place of an exception handling mechanism.

Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain.

There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` has no intuitive meaning whatsoever. It says absolutely nothing about what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result<T> you actually want to define your own enum so you can attach meaning to the value.

You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result<T,E> type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).

We recognize that Result conveys a particular semantics that encourage this type to cross over into the error-handling domain. As noted in the proposal, we don’t want to emphasize this case because a version of this proposal was already rejected for overlapping too heavily with throws. If the community feels that the proposal deserves to be rewritten in a way that re-emphasizes this case and makes that point then I am up for it. But, I request that this not be used as an argument to reduce the genericity of the type - which is to say I don’t wish to see a Result<T> or a Result<T, E : ErrorType> because they reduce the power of the original proposal.

When I use the term genericity, I am not arguing for the naming scheme of the Either we have, I’m arguing for the structure to be kept around as-is. My biggest fear is that a Result with one lobe and an Error is going to be merged rather than the full proposal because this type and the discussion of it outside of here can become too absorbed in the error-handling case. I do not wish to lose the structure of the type we have now, because that structure is precisely what a future Swift could generalize and abstract upon. The name, however, is up for grabs. We offer a list of alternatives at the end of the proposal, if you have any more to suggest please reply to me here and I’ll see about adding them.

At the same time, it has been brought up that Either conveys no immediate useful information. At the time of writing this proposal, we do not believe that to be the case, but we recognize that by naming this Result we can reach a wider audience. At the end of the day the proposal is about merging in a 2-case sum type. We chose Either not because we wanted to see it merged, but precisely because it was so meaning-agnostic. It’s our lorem-ipsum. For those that think we’re trying to merge a Haskell-ism, I can say with complete confidence that no part of TypeLift intended that in the original proposal. Whatever bad taste Haskell may have left in anybody’s mouth, the Either in our proposal is a placeholder for a name to be decided upon by the community. I felt that this was clear from the line

though other names may be appropriate depending on how the type is implemented.

and

In addition, the name `Either` does not lend much to the imagination,
and the use of `Left` and `Right` have the potential to cause confusion to
novices expecting a `Result<T>`

in the original proposal, but I was wrong. I have updated the draft accordingly.

Besides, even if the type in the proposal were to be merged right this very second, “meaningless" names and all, a domain-specific Result type could easily be recovered from it. The same is not true of a type that is immediately domain-specific like the reduced-generic forms of Result. To translate that into the language of Result using Either as a template: If a Result<T, E> were not merged, then it could not be recovered from Result<T> in any meaningful manner. However, a constrained Result<T, E : ErrorType> can be recovered from the fully generic type in the proposal.

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names. Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?

This is in line with the goals of the proposal and I would certainly support this renaming if it serves the community’s best interest. You all are, by now, aware of my qualms with the name, but I’m not one to dwell on these things when we’ve made it clear in the proposal that the type can go by many names. It’s the structure of a sum that we’re after, and we’re willing to take it how it comes - but contingent on the shape of the type not differing from the proposal as written. I request that if the name Result be brought up again, that it come with the specific number and kind of parameters involved so we can nail down the shape being discussed.

The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples. However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements. Your Either type has neither of these features.

Contrary to the impression the other discussion has made, nowhere in the proposal do we wish to augment the type system. If this is done correctly, the type in the proposal should be a ~40-line addition to the standard library, it should not wind up as a full-blown language change. We are not advocating for an n-element sum type, nor are we arguing for a structural typing scheme that would put variadic sums in the language because we recognize that solution is untenable. We are, however, advocating for the inclusion of a 2-case sum type we happen to call Either in writing.

The type system already supports N-ary “either” types. We call them enums.

This is another example of exactly why Either is terrible in practice. I understand that from a type algebra point of view this is perfectly reasonable and clean and that a 2-way sum is all that is necessary because larger sums are easily created by construction. Type theory-wise it’s lovely.

Because this is a non-goal of the type. The sum as presented in the proposal does not attempt to take the place of enums, nor does it make any bones about being a finite entity. We are specifically emphasizing the two-element case. Any other arguments that pertain to its inclusion as a feature of the type system should start at the last site of discussion and probably terminate in a separate proposal adding that kind of scheme to the Swift language itself. We are arguing for a simple change to the standard library, nothing more.

As before, unlike `throws`, a disjoint union type can be applied in arbitrary
positions, used as a member, and easily checked for completeness
at compile time. In addition, the lack of a standard union type has
led the Swift community to create [numerous](https://github.com/search?utf8=✓&q=Either+language%3Aswift <https://github.com/search?utf8=✓&q=Either+language%3Aswift&gt;\) duplicate implementations of the
same mutually incompatible types over and over and over again. In the
interest of promoting a type that there has received clear interest by the
community, the addition to the Standard Library is necessary.

The argument is not “let’s toss out all implementations of 2-case enums in favor of this sum” it’s “very often, when you’ve got a two-case enum with bias, you’ve got a sum described in the proposal”. This pattern shows up in a sufficiently large number of cases that we feel that the standard library deserves to have the final say as to a community-guided implementation of this type because individual implementations seem to differ only in a few minor places like naming or generic positions.

I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.

This is another motivating factor that lines up with a major tenant of the proposal. We would not be suggesting this change to the standard library if we did not see this pattern show up in a number of large frameworks, applications, and everything in between. We offer a section of motivating examples and links that should convince you of its commonality if that is still a sticking point.

I’d say “works”, not works; the ergonomics are terrible, you are unlikely to be able to take advantage of the bias anymore, and even if we overlook all that, you still have to enforce an external convention to get mutual-interoperability at each n; otherwise, you may say Either<Either<,>,Either<,>> but I may say Either<Either<Either<,>,>,> and someone else may say Either<,Either<,Either<,>>> and someone else says Either<,Either<Either<,>,>> and so on…

This point, while valid, is also an unfortunate feature of Optionals as well, which I have argued can be viewed as an Sum with one lobe “sealed” by Top, the empty tuple. I have yet to see a use of a sum type that needs nesting like this, nor have I seen any type or type alias that attempts to use this to recover an n-ary Sum because it just doesn’t happen. If you have a disjoint set of possibilities with order greater than two, as Chris noted, Swift already offers enums. And if such a case has arisen, it needs to be refactored just as Optional<Optional<Optional<...>>> would be.

* An either-like type should be named something meaningful for the context it is used

See above.

* There are a lot of cases where an either-like type is useful, there may generalised functions that are often used on them

See proposal.

* Is defining or re-defining an either type hard?

See proposal.

* Is it too niche to be in the standard library

We don’t believe so, see proposal.

No, I take issue with the entire fundamental idea behind your proposal. You've explicitly defined this type purely by its shape, with no meaning whatsoever given to either variant, except insofar as the type is Left-biased (which only serves to be even more confusing; since there's no actual meaning assigned to Left/Right, what is the justification for adding the left-biasing?)

The rationale given for bias has been updated in the latest draft.

tl;dr

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.

On Jan 20, 2016, at 10:17 PM, Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1.

There have been discussions about generic typealiases/newtypes on this list before. If getting something in for Swift 2 isn't a must-have, I wonder if we could leverage those features to make both camps happy. Being able to partially apply a generic type to form a new generic type would allow us to have something like:

enum Either<T, U> {
  case Left<T>, Right<U>
}

typealias Result<GoodType> = Either< GoodType, ErrorType>

Of course, the above raises the question as to whether an 'Either' that just happens to have the right type be an ErrorType should be interchangeable with the corresponding 'Result', etc.

However, the above proposal might be infeasible from a theoretical or implementation perspective; if that's the case let's not get sidetracked :).

Best,
Austin

···

On Jan 22, 2016, at 10:22 PM, Developer via swift-evolution <swift-evolution@swift.org> wrote:

My overwhelming concern, after having a conversation with Chris, is that implementing a Result<T> means we are strongly implying a particular semantics and use case when we could generalize and abstract for no cost but an extra generic parameter. In F#, Core.Choice can be used to build a Validation or Result monad, but the converse is impossible.

~Robert Widmann

2016/01/23 1:05、Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain. I'm not 100% sure about func alternate in Madness/Alternation.swift. It definitely uses Left/Right to mean Failure/Result, but I couldn't tell if it also uses them as something else. Which makes those names all the more maddening.

I checked my company's largest Scala project, which is over 300,000 lines. We use Scala's Try/Success/Failure in dozens of places. We use Either/Left/Right once, in a thrown-together report-generating script, which would probably have been written in awk or perl if it didn't need to read binary log files. (The ability of IntelliJ to reliably find all uses of a class or method is not to be underestimated. Hint hint, team Xcode.)

I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Precisely. That's the plan.

Even if that doesn't go through, it isn't hard to just wrap it or declare a typealias yourself in an enum with no cases:

enum Result<E : ErrorType, T> {
   typealias T = Either<E, T>
}

func foo() -> Result<FooErrorType, ResultType> {
    //...
}

~Robert Widmann

2016/01/23 1:34、Austin Zheng <austinzheng@gmail.com> のメッセージ:

···

+1.

There have been discussions about generic typealiases/newtypes on this list before. If getting something in for Swift 2 isn't a must-have, I wonder if we could leverage those features to make both camps happy. Being able to partially apply a generic type to form a new generic type would allow us to have something like:

enum Either<T, U> {
  case Left<T>, Right<U>
}

typealias Result<GoodType> = Either< GoodType, ErrorType>

Of course, the above raises the question as to whether an 'Either' that just happens to have the right type be an ErrorType should be interchangeable with the corresponding 'Result', etc.

However, the above proposal might be infeasible from a theoretical or implementation perspective; if that's the case let's not get sidetracked :).

Best,
Austin

On Jan 22, 2016, at 10:22 PM, Developer via swift-evolution <swift-evolution@swift.org> wrote:

My overwhelming concern, after having a conversation with Chris, is that implementing a Result<T> means we are strongly implying a particular semantics and use case when we could generalize and abstract for no cost but an extra generic parameter. In F#, Core.Choice can be used to build a Validation or Result monad, but the converse is impossible.

~Robert Widmann

2016/01/23 1:05、Rob Mayoff via swift-evolution <swift-evolution@swift.org> のメッセージ:

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain. I'm not 100% sure about func alternate in Madness/Alternation.swift. It definitely uses Left/Right to mean Failure/Result, but I couldn't tell if it also uses them as something else. Which makes those names all the more maddening.

I checked my company's largest Scala project, which is over 300,000 lines. We use Scala's Try/Success/Failure in dozens of places. We use Either/Left/Right once, in a thrown-together report-generating script, which would probably have been written in awk or perl if it didn't need to read binary log files. (The ability of IntelliJ to reliably find all uses of a class or method is not to be underestimated. Hint hint, team Xcode.)

I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Unfortunately, it is tied down to quite a few functional concepts (assuming you mean the Scalaz version of Validation). For starters (apologies, I misspoke in the last reply), it’s only an Applicative and the standard library only provides Functor and Monad-like concepts. On top of that, errors will have to pass through a Semigroup, something only Swiftz provides at the moment.

Seems the most extra power you can get is `Result<T>` at the current level of abstraction the Standard Library is at.

···

On Jan 23, 2016, at 6:41 PM, Craig Cruden <ccruden@novafore.com> wrote:

I would think that if Either is in core — and Validation is not to dependent on other functional concepts (too deeply tied to the rest of Swiftz) — and being a very core concept for any application that it would be bundled with Either in standard libraries as well. Pretty well every business application — large or small — functional or not — would benefit from a very easy /non-verbose validation mechanism.

I view Either conceptually as part of the contract that a function provides (normal validation; e.g. Person’s birth cannot be future-dated) which is expected as part of the functions process…. (and are expected and will be dealt with by whatever is calling it)…. while Exceptions are for exceptional circumstances / technical failings that may not be expected during normal operation such as a catastrophic fail (e.g. Server not found). An Either/Validation business validation would be returned in a message on the same server or to a calling service, while technical failings might do things like fail-over.

Not sure if I am expressing myself correctly.

On 2016-01-23, at 13:32:06, Developer <devteam.codafi@gmail.com> wrote:

Yes, you definitely can use this Either to recover the Validation monad a la Scala. I think I have to draw up an implementation and submit it to Swiftz!

~Robert Widmann

2016/01/22 23:45、Craig Cruden <ccruden@novafore.com> のメッセージ:

I was reading the proposal and I have to admit I do like Either and have used it extensively in Scala for normal exceptions (business validations) leaving exceptions to … exceptional circumstances. If I went back I think I could get rid of quite a bit of stuff if I had put more thought into it.

When it comes to validations though I was wondering how you saw it coming together:

i.e. you have a set of validations that you run (independent validations) where after you finished if any of them has a validation you just want a list of business exceptions.

The other scenario I could see is dependent validations where certain validations you want to skip because a validation that it was dependent on failed - i.e. you don’t want to be flooded with other validations which occur solely due to an earlier failed validation. (i.e. concise execution of a list of validations or something like that).

On 2016-01-21, at 10:17:34, Developer via swift-evolution <swift-evolution@swift.org> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

OK, So If the eventual proposal for HKT get added - then Validation would flow fairly nicely (if it is only Semigroup in the way — that I gather would be a fairly small add to get such power in the standard language).

···

On 2016-01-24, at 6:56:28, Developer <devteam.codafi@gmail.com> wrote:

Unfortunately, it is tied down to quite a few functional concepts (assuming you mean the Scalaz version of Validation). For starters (apologies, I misspoke in the last reply), it’s only an Applicative and the standard library only provides Functor and Monad-like concepts. On top of that, errors will have to pass through a Semigroup, something only Swiftz provides at the moment.

Seems the most extra power you can get is `Result<T>` at the current level of abstraction the Standard Library is at.

On Jan 23, 2016, at 6:41 PM, Craig Cruden <ccruden@novafore.com> wrote:

I would think that if Either is in core — and Validation is not to dependent on other functional concepts (too deeply tied to the rest of Swiftz) — and being a very core concept for any application that it would be bundled with Either in standard libraries as well. Pretty well every business application — large or small — functional or not — would benefit from a very easy /non-verbose validation mechanism.

I view Either conceptually as part of the contract that a function provides (normal validation; e.g. Person’s birth cannot be future-dated) which is expected as part of the functions process…. (and are expected and will be dealt with by whatever is calling it)…. while Exceptions are for exceptional circumstances / technical failings that may not be expected during normal operation such as a catastrophic fail (e.g. Server not found). An Either/Validation business validation would be returned in a message on the same server or to a calling service, while technical failings might do things like fail-over.

Not sure if I am expressing myself correctly.

On 2016-01-23, at 13:32:06, Developer <devteam.codafi@gmail.com> wrote:

Yes, you definitely can use this Either to recover the Validation monad a la Scala. I think I have to draw up an implementation and submit it to Swiftz!

~Robert Widmann

2016/01/22 23:45、Craig Cruden <ccruden@novafore.com> のメッセージ:

I was reading the proposal and I have to admit I do like Either and have used it extensively in Scala for normal exceptions (business validations) leaving exceptions to … exceptional circumstances. If I went back I think I could get rid of quite a bit of stuff if I had put more thought into it.

When it comes to validations though I was wondering how you saw it coming together:

i.e. you have a set of validations that you run (independent validations) where after you finished if any of them has a validation you just want a list of business exceptions.

The other scenario I could see is dependent validations where certain validations you want to skip because a validation that it was dependent on failed - i.e. you don’t want to be flooded with other validations which occur solely due to an earlier failed validation. (i.e. concise execution of a list of validations or something like that).

On 2016-01-21, at 10:17:34, Developer via swift-evolution <swift-evolution@swift.org> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

There absolutely is a cost. `Result<T>` has a rather intuitive meaning.
`Either<T>` has *no intuitive meaning whatsoever*. It says absolutely
*nothing* about what it means beyond the fact that there are two
potential values. As a result, it is a largely useless type whose sole
redeeming feature is it allows developers to avoid having to define
their own enum, but in most cases that aren't covered by Result<T> you
actually *want* to define your own enum so you can attach meaning to
the value.

If it's not obvious, I'm very strongly against having a generic Either
type, but I do want a Result<T> or Result<T,E>.

-Kevin Ballard

···

On Fri, Jan 22, 2016, at 10:22 PM, Developer via swift-evolution wrote:

My overwhelming concern, after having a conversation with Chris, is
that implementing a Result<T> means we are strongly implying a
particular semantics and use case when we could generalize and
abstract for no cost but an extra generic parameter. In F#,
Core.Choice can be used to build a Validation or Result monad, but the
converse is impossible.

~Robert Widmann

2016/01/23 1:05、Rob Mayoff via swift-evolution <swift-
evolution@swift.org> のメッセージ:

Just added a section of motivating examples to the Either proposal.
Ping me if you have any more that I missed ('cause I'm sure I did
miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

Your motivating examples (including all the projects you linked
except "Any many more") overwhelmingly use the Either (or similar
type) to represent success/failure. I'm not sure there's a single
example where the names Left and Right actually make sense in the
problem domain. I'm not 100% sure about func alternate in
Madness/Alternation.swift. It definitely uses Left/Right to mean
Failure/Result, but I couldn't tell if it also uses them as something
else. Which makes those names all the more maddening.

I checked my company's largest Scala project, which is over 300,000
lines. We use Scala's Try/Success/Failure in dozens of places. We use
Either/Left/Right once, in a thrown-together report-generating
script, which would probably have been written in awk or perl if it
didn't need to read binary log files. (The ability of IntelliJ to
reliably find all uses of a class or method is not to be
underestimated. Hint hint, team Xcode.)

I think a Result/Success/Failure type is warranted, but I'm very
skeptical about generic Either/Left/Right.

_______________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

FWIW, I think a preferable alternative to an Either or Result type is union types, which could work as a sort of on-the-fly enum. Silly example:

func getNameOrAge() ->|String, Int| { // or maybe enum(String, Int)
if true {
return "Butterscotch"
} else {
return 25
}
}

switch getNameOrAge() {
case String(let name): print("Name: \(name)")
case Int(let age):print("Age: \(age)")
}

I've run into a couple situations where I've needed to return different types from some one-off function (outside of the result/error pattern), but didn't want to create another type for that hyper-specific use case, and I wished I had some way of inlining a one-off, either-or type. It's even temping to use a tuple with optional values to leverage its inlining behavior, but that produces extra unwanted code paths. Union types are a powerful and use-case-agnostic solution to that kind of problem.

Jarod

···

On Jan 26, 2016, 21:27 -0800, Craig Cruden via swift-evolution<swift-evolution@swift.org>, wrote:

The other minor point is that this type (TBD) may not in fact be a result of function (of which everything returned from a function is in fact a result) would be an erroneous name.

> On 2016-01-27, at 12:09:07, Developer via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> Hello all,
>
> I’m going to try and round up a summary of arguments for and against this proposal and my response to them, because I think there is a clear sense in everybody’s mind what Either entails, but that sense differs widely depending on individual interactions with the parts of the proposal.I take full responsibility for the rhetoric and the style of debate that has been going on for the past ~24 hours.It was borderline unprofessional the way this was going and I want to apologize now to those involved for being so very unclear in my reasoning and my rhetoric as to stir up a senseless debate about points we essentially agreed on beforehand.As such, I’ve made some revisions to the proposal, I request that you all please re-read it (athttps://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md) before we try again so we can refocus this debate on more productive avenues of discourse.
>
> Throughout this reply I’ve made heavy use of quotes from other replies.Those will appear in purple.Quotes from the proposal will appear in blue.
>
> The type “Either” that we describe in the proposal is a placeholder.I feel that must be emphasized, because there have been arguments about the name.We specifically mention this in the proposal:
>
> > The Swift Standard Library will be updated to include a left-biased sum type we have calledEither- though other names may be appropriate depending on how the type is implemented.
>
> What we are requesting is a finite-case, here precisely two-case, type that represents two disjoint possibilities.As noted before, this type is often called Result by Swift framework authors and notably the programming language Rust which uses it in place of an exception handling mechanism.
>
> > Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain.
> > There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` hasno intuitive meaning whatsoever. It says absolutelynothingabout what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result<T>you actuallywantto define your own enum so you can attach meaning to the value.
>
> > You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result<T,E>type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).
>
> We recognize that Result conveys a particular semantics that encourage this type to cross over into the error-handling domain.As noted in the proposal, we don’t want to emphasize this case because a version of this proposal was already rejected for overlapping too heavily with throws.If the community feels that the proposal deserves to be rewritten in a way that re-emphasizes this case and makes that point then I am up for it.But, I request that this not be used as an argument to reduce the genericity of the type - which is to say I don’t wish to see a Result<T>or a Result<T, E : ErrorType>because they reduce the power of the original proposal.
>
> When I use the term genericity, I am not arguing for the naming scheme of the Either we have, I’m arguing for the structure to be kept around as-is.My biggest fear is that a Result with one lobe and an Error is going to be merged rather than the full proposal because this type and the discussion of it outside of here can become too absorbed in the error-handling case.I do not wish to lose the structure of the type we have now, because that structure is precisely what a future Swift could generalize and abstract upon.The name, however, is up for grabs.We offer a list of alternatives at the end of the proposal, if you have any more to suggest please reply to me here and I’ll see about adding them.
>
> At the same time, it has been brought up that Either conveys no immediate useful information.At the time of writing this proposal, we do not believe that to be the case, but we recognize that by naming this Result we can reach a wider audience.At the end of the day the proposal is about merging in a 2-case sum type.We chose Either not because we wanted to see it merged, but preciselybecause it was so meaning-agnostic.It’s our lorem-ipsum.For those that think we’re trying to merge a Haskell-ism, I can say with complete confidence that no part of TypeLift intended that in the original proposal.Whatever bad taste Haskell may have left in anybody’s mouth, the Either in our proposal is a placeholder for a name to be decided upon by the community.I felt that this was clear from the line
>
> > though other names may be appropriate depending on how the type is implemented.
>
> and
>
> > In addition, the name `Either` does not lend much to the imagination,
> > and the use of `Left` and `Right` have the potential to cause confusion to
> > novices expecting a `Result<T>`
>
>
>
> in the original proposal, but I was wrong.I have updated the draft accordingly.
>
> Besides, even if the type in the proposal were to be merged right this very second, “meaningless" names and all, a domain-specific Result type could easily be recovered from it.The same is not true of a type that is immediately domain-specific like the reduced-generic forms of Result.To translate that into the language of Result using Either as a template: If a Result<T, E>were not merged, then it could not be recovered from Result<T>in any meaningful manner.However, a constrained Result<T, E : ErrorType>canbe recovered from the fully generic type in the proposal.
>
> > I agree with Kevin and others that we’re likely to be destined to introduce a real Result type.This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?
> This is in line with the goals of the proposal and I would certainly support this renaming if it serves the community’s best interest.You all are, by now, aware of my qualms with the name, but I’m not one to dwell on these things when we’ve made it clear in the proposal that the type can go by many names.It’s the structure of a sum that we’re after, and we’re willing to take it how it comes - but contingent on the shape of the type not differing from the proposal as written.I request that if the name Result be brought up again, that it come with the specific number and kind of parameters involved so we can nail down the shape being discussed.
>
> > The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples.However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements.Your Either type has neither of these features.
>
> Contrary to the impression the other discussion has made, nowhere in the proposal do we wish to augment the type system.If this is done correctly, the type in the proposal should be a ~40-line addition to the standard library, it should not wind up as a full-blown language change.We are not advocating for an n-element sum type, nor are we arguing for a structural typing scheme that would put variadic sums in the language because we recognize that solution is untenable.We are, however, advocating for the inclusion of a 2-case sum type we happen to call Either in writing.
>
> > The type system already supports N-ary “either” types.We call them enums.
>
> > This is another example of exactly why Either is terrible in practice. I understand that from a type algebra point of view this is perfectly reasonable and clean and that a 2-way sum is all that is necessary because larger sums are easily created by construction. Type theory-wise it’s lovely.
>
> Because this is a non-goal of the type. The sum as presented in the proposal does not attempt to take the place of enums, nor does it make any bones about being a finite entity.We are specifically emphasizing the two-element case.Any other arguments that pertain to its inclusion as a feature of the type system should start at the last site of discussion and probably terminate in a separate proposal adding that kind of scheme to the Swift language itself.We are arguing for a simple change to the standard library, nothing more.
>
> > As before, unlike `throws`, a disjoint union type can be applied in arbitrary
> > positions, used as a member, and easily checked for completeness
> > at compile time.In addition, the lack of a standard union type has
> > led the Swift community to create [numerous](https://github.com/search?utf8=✓&q=Either+language%3Aswift(https://github.com/search?utf8=✓&q=Either+language%3Aswift)\) duplicate implementations of the
> > same mutually incompatible types over and over and over again.In the
> > interest of promoting a type that there has received clear interest by the
> > community, the addition to the Standard Library is necessary.
>
>
>
> The argument is not “let’s toss out all implementations of 2-case enums in favor of this sum” it’s “very often, when you’ve got a two-case enum with bias, you’ve got a sum described in the proposal”.This pattern shows up in a sufficiently large number of cases that we feel that the standard library deserves to have the final say as to a community-guided implementation of this type because individual implementations seem to differ only in a few minor places like naming or generic positions.
>
> > I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.
>
> This is another motivating factor that lines up with a major tenant of the proposal.We would not be suggesting this change to the standard library if we did not see this pattern show up in a number of large frameworks, applications, and everything in between.We offer a section of motivating examples and links that should convince you of its commonality if that is still a sticking point.
>
> > I’d say “works”, not works; the ergonomics are terrible, you are unlikely to be able to take advantage of the bias anymore, and even if we overlook all that, you still have to enforce an external convention to get mutual-interoperability at each n; otherwise, you may say Either<Either<,>,Either<,>>but I may say Either<Either<Either<,>,>,>and someone else may say Either<,Either<,Either<,>>>and someone else says Either<,Either<Either<,>,>>and so on…
>
> This point, while valid, is also an unfortunate feature of Optionals as well, which I have argued can be viewed as an Sum with one lobe “sealed” by Top, the empty tuple.I have yet to see a use of a sum type that needs nesting like this, nor have I seen any type or type alias that attempts to use this to recover an n-ary Sum because it just doesn’t happen.If you have a disjoint set of possibilities with order greater than two, as Chris noted, Swift already offers enums.And if such a case has arisen, it needs to be refactored just as Optional<Optional<Optional<...>>>would be.
>
> > * An either-like type should be named something meaningful for the context it is used
>
> See above.
> > * There are a lot of cases where an either-like type is useful, there may generalised functions that are often used on them
>
> See proposal.
> > * Is defining or re-defining an either type hard?
>
> See proposal.
>
> > * Is it too niche to be in the standard library
>
> We don’t believe so, see proposal.
>
> > No, I take issue with the entire fundamental idea behind your proposal. You've explicitly defined this type purely by its shape, with no meaning whatsoever given to either variant, except insofar as the type is Left-biased (which only serves to be even more confusing; since there's no actual meaning assigned to Left/Right, what is the justification for adding the left-biasing?)
>
> The rationale given for bias has been updated in the latest draft.
>
> tl;dr
>
> > I agree with Kevin and others that we’re likely to be destined to introduce a real Result type.This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.
>
> > On Jan 20, 2016, at 10:17 PM, Developer<devteam.codafi@gmail.com(mailto:devteam.codafi@gmail.com)>wrote:
> > Hey all,
> >
> > Just added a section of motivating examples to the Either proposal.Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).
> >
> > https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples
> >
> > ~Robert Widmann
> >
> > 2016/01/09 14:19、Developer<devteam.codafi@gmail.com(mailto:devteam.codafi@gmail.com)>のメッセージ:
> >
> > > Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library.The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).
> > >
> > > Thanks all!
> > >
> > > ~Robert Widmann
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I hadn't, thanks for pointing me in the right direction.

Jarod

···

On Jan 26, 2016, 21:48 -0800, Developer<devteam.codafi@gmail.com>, wrote:

Have you seen the last round of discussions (roothttps://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html)?I don’t want to continue discussing this specific thing here because it is outside the scope of the proposal as it stands.

> On Jan 27, 2016, at 12:46 AM, Jarod Long via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> FWIW, I think a preferable alternative to an Either or Result type is union types, which could work as a sort of on-the-fly enum. Silly example:
>
> func getNameOrAge() ->|String, Int| { // or maybe enum(String, Int)
> if true {
> return "Butterscotch"
> } else {
> return 25
> }
> }
>
> switch getNameOrAge() {
> case String(let name): print("Name: \(name)")
> case Int(let age):print("Age: \(age)")
> }
>
> I've run into a couple situations where I've needed to return different types from some one-off function (outside of the result/error pattern), but didn't want to create another type for that hyper-specific use case, and I wished I had some way of inlining a one-off, either-or type. It's even temping to use a tuple with optional values to leverage its inlining behavior, but that produces extra unwanted code paths. Union types are a powerful and use-case-agnostic solution to that kind of problem.
>
> Jarod
>
>
> On Jan 26, 2016, 21:27 -0800, Craig Cruden via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>, wrote:
> > The other minor point is that this type (TBD) may not in fact be a result of function (of which everything returned from a function is in fact a result) would be an erroneous name.
> >
> > > On 2016-01-27, at 12:09:07, Developer via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > > Hello all,
> > >
> > > I’m going to try and round up a summary of arguments for and against this proposal and my response to them, because I think there is a clear sense in everybody’s mind what Either entails, but that sense differs widely depending on individual interactions with the parts of the proposal.I take full responsibility for the rhetoric and the style of debate that has been going on for the past ~24 hours.It was borderline unprofessional the way this was going and I want to apologize now to those involved for being so very unclear in my reasoning and my rhetoric as to stir up a senseless debate about points we essentially agreed on beforehand.As such, I’ve made some revisions to the proposal, I request that you all please re-read it (athttps://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md) before we try again so we can refocus this debate on more productive avenues of discourse.
> > >
> > > Throughout this reply I’ve made heavy use of quotes from other replies.Those will appear in purple.Quotes from the proposal will appear in blue.
> > >
> > > The type “Either” that we describe in the proposal is a placeholder.I feel that must be emphasized, because there have been arguments about the name.We specifically mention this in the proposal:
> > >
> > > > The Swift Standard Library will be updated to include a left-biased sum type we have calledEither- though other names may be appropriate depending on how the type is implemented.
> > >
> > > What we are requesting is a finite-case, here precisely two-case, type that represents two disjoint possibilities.As noted before, this type is often called Result by Swift framework authors and notably the programming language Rust which uses it in place of an exception handling mechanism.
> > >
> > > > Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain.
> > > > There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` hasno intuitive meaning whatsoever. It says absolutelynothingabout what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result<T>you actuallywantto define your own enum so you can attach meaning to the value.
> > >
> > > > You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result<T,E>type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).
> > >
> > > We recognize that Result conveys a particular semantics that encourage this type to cross over into the error-handling domain.As noted in the proposal, we don’t want to emphasize this case because a version of this proposal was already rejected for overlapping too heavily with throws.If the community feels that the proposal deserves to be rewritten in a way that re-emphasizes this case and makes that point then I am up for it.But, I request that this not be used as an argument to reduce the genericity of the type - which is to say I don’t wish to see a Result<T>or a Result<T, E : ErrorType>because they reduce the power of the original proposal.
> > >
> > > When I use the term genericity, I am not arguing for the naming scheme of the Either we have, I’m arguing for the structure to be kept around as-is.My biggest fear is that a Result with one lobe and an Error is going to be merged rather than the full proposal because this type and the discussion of it outside of here can become too absorbed in the error-handling case.I do not wish to lose the structure of the type we have now, because that structure is precisely what a future Swift could generalize and abstract upon.The name, however, is up for grabs.We offer a list of alternatives at the end of the proposal, if you have any more to suggest please reply to me here and I’ll see about adding them.
> > >
> > > At the same time, it has been brought up that Either conveys no immediate useful information.At the time of writing this proposal, we do not believe that to be the case, but we recognize that by naming this Result we can reach a wider audience.At the end of the day the proposal is about merging in a 2-case sum type.We chose Either not because we wanted to see it merged, but preciselybecause it was so meaning-agnostic.It’s our lorem-ipsum.For those that think we’re trying to merge a Haskell-ism, I can say with complete confidence that no part of TypeLift intended that in the original proposal.Whatever bad taste Haskell may have left in anybody’s mouth, the Either in our proposal is a placeholder for a name to be decided upon by the community.I felt that this was clear from the line
> > >
> > > > though other names may be appropriate depending on how the type is implemented.
> > >
> > > and
> > >
> > > > In addition, the name `Either` does not lend much to the imagination,
> > > > and the use of `Left` and `Right` have the potential to cause confusion to
> > > > novices expecting a `Result<T>`
> > >
> > >
> > >
> > > in the original proposal, but I was wrong.I have updated the draft accordingly.
> > >
> > > Besides, even if the type in the proposal were to be merged right this very second, “meaningless" names and all, a domain-specific Result type could easily be recovered from it.The same is not true of a type that is immediately domain-specific like the reduced-generic forms of Result.To translate that into the language of Result using Either as a template: If a Result<T, E>were not merged, then it could not be recovered from Result<T>in any meaningful manner.However, a constrained Result<T, E : ErrorType>canbe recovered from the fully generic type in the proposal.
> > >
> > > > I agree with Kevin and others that we’re likely to be destined to introduce a real Result type.This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?
> > > This is in line with the goals of the proposal and I would certainly support this renaming if it serves the community’s best interest.You all are, by now, aware of my qualms with the name, but I’m not one to dwell on these things when we’ve made it clear in the proposal that the type can go by many names.It’s the structure of a sum that we’re after, and we’re willing to take it how it comes - but contingent on the shape of the type not differing from the proposal as written.I request that if the name Result be brought up again, that it come with the specific number and kind of parameters involved so we can nail down the shape being discussed.
> > >
> > > > The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples.However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements.Your Either type has neither of these features.
> > >
> > > Contrary to the impression the other discussion has made, nowhere in the proposal do we wish to augment the type system.If this is done correctly, the type in the proposal should be a ~40-line addition to the standard library, it should not wind up as a full-blown language change.We are not advocating for an n-element sum type, nor are we arguing for a structural typing scheme that would put variadic sums in the language because we recognize that solution is untenable.We are, however, advocating for the inclusion of a 2-case sum type we happen to call Either in writing.
> > >
> > > > The type system already supports N-ary “either” types.We call them enums.
> > >
> > > > This is another example of exactly why Either is terrible in practice. I understand that from a type algebra point of view this is perfectly reasonable and clean and that a 2-way sum is all that is necessary because larger sums are easily created by construction. Type theory-wise it’s lovely.
> > >
> > > Because this is a non-goal of the type. The sum as presented in the proposal does not attempt to take the place of enums, nor does it make any bones about being a finite entity.We are specifically emphasizing the two-element case.Any other arguments that pertain to its inclusion as a feature of the type system should start at the last site of discussion and probably terminate in a separate proposal adding that kind of scheme to the Swift language itself.We are arguing for a simple change to the standard library, nothing more.
> > >
> > > > As before, unlike `throws`, a disjoint union type can be applied in arbitrary
> > > > positions, used as a member, and easily checked for completeness
> > > > at compile time.In addition, the lack of a standard union type has
> > > > led the Swift community to create [numerous](https://github.com/search?utf8=✓&q=Either+language%3Aswift(https://github.com/search?utf8=✓&q=Either+language%3Aswift)\) duplicate implementations of the
> > > > same mutually incompatible types over and over and over again.In the
> > > > interest of promoting a type that there has received clear interest by the
> > > > community, the addition to the Standard Library is necessary.
> > >
> > >
> > >
> > > The argument is not “let’s toss out all implementations of 2-case enums in favor of this sum” it’s “very often, when you’ve got a two-case enum with bias, you’ve got a sum described in the proposal”.This pattern shows up in a sufficiently large number of cases that we feel that the standard library deserves to have the final say as to a community-guided implementation of this type because individual implementations seem to differ only in a few minor places like naming or generic positions.
> > >
> > > > I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.
> > >
> > > This is another motivating factor that lines up with a major tenant of the proposal.We would not be suggesting this change to the standard library if we did not see this pattern show up in a number of large frameworks, applications, and everything in between.We offer a section of motivating examples and links that should convince you of its commonality if that is still a sticking point.
> > >
> > > > I’d say “works”, not works; the ergonomics are terrible, you are unlikely to be able to take advantage of the bias anymore, and even if we overlook all that, you still have to enforce an external convention to get mutual-interoperability at each n; otherwise, you may say Either<Either<,>,Either<,>>but I may say Either<Either<Either<,>,>,>and someone else may say Either<,Either<,Either<,>>>and someone else says Either<,Either<Either<,>,>>and so on…
> > >
> > > This point, while valid, is also an unfortunate feature of Optionals as well, which I have argued can be viewed as an Sum with one lobe “sealed” by Top, the empty tuple.I have yet to see a use of a sum type that needs nesting like this, nor have I seen any type or type alias that attempts to use this to recover an n-ary Sum because it just doesn’t happen.If you have a disjoint set of possibilities with order greater than two, as Chris noted, Swift already offers enums.And if such a case has arisen, it needs to be refactored just as Optional<Optional<Optional<...>>>would be.
> > >
> > > > * An either-like type should be named something meaningful for the context it is used
> > >
> > > See above.
> > > > * There are a lot of cases where an either-like type is useful, there may generalised functions that are often used on them
> > >
> > > See proposal.
> > > > * Is defining or re-defining an either type hard?
> > >
> > > See proposal.
> > >
> > > > * Is it too niche to be in the standard library
> > >
> > > We don’t believe so, see proposal.
> > >
> > > > No, I take issue with the entire fundamental idea behind your proposal. You've explicitly defined this type purely by its shape, with no meaning whatsoever given to either variant, except insofar as the type is Left-biased (which only serves to be even more confusing; since there's no actual meaning assigned to Left/Right, what is the justification for adding the left-biasing?)
> > >
> > > The rationale given for bias has been updated in the latest draft.
> > >
> > > tl;dr
> > >
> > > > I agree with Kevin and others that we’re likely to be destined to introduce a real Result type.This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.
> > >
> > > > On Jan 20, 2016, at 10:17 PM, Developer<devteam.codafi@gmail.com(mailto:devteam.codafi@gmail.com)>wrote:
> > > > Hey all,
> > > >
> > > > Just added a section of motivating examples to the Either proposal.Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).
> > > >
> > > > https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples
> > > >
> > > > ~Robert Widmann
> > > >
> > > > 2016/01/09 14:19、Developer<devteam.codafi@gmail.com(mailto:devteam.codafi@gmail.com)>のメッセージ:
> > > >
> > > > > Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library.The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).
> > > > >
> > > > > Thanks all!
> > > > >
> > > > > ~Robert Widmann
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution

Have you seen the last round of discussions (root https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\)? I don’t want to continue discussing this specific thing here because it is outside the scope of the proposal as it stands.

···

On Jan 27, 2016, at 12:46 AM, Jarod Long via swift-evolution <swift-evolution@swift.org> wrote:

FWIW, I think a preferable alternative to an Either or Result type is union types, which could work as a sort of on-the-fly enum. Silly example:

func getNameOrAge() -> |String, Int| { // or maybe enum(String, Int)
    if true {
        return "Butterscotch"
    } else {
        return 25
    }
}

switch getNameOrAge() {
    case String(let name): print("Name: \(name)")
    case Int(let age): print("Age: \(age)")
}

I've run into a couple situations where I've needed to return different types from some one-off function (outside of the result/error pattern), but didn't want to create another type for that hyper-specific use case, and I wished I had some way of inlining a one-off, either-or type. It's even temping to use a tuple with optional values to leverage its inlining behavior, but that produces extra unwanted code paths. Union types are a powerful and use-case-agnostic solution to that kind of problem.

Jarod

On Jan 26, 2016, 21:27 -0800, Craig Cruden via swift-evolution <swift-evolution@swift.org>, wrote:

The other minor point is that this type (TBD) may not in fact be a result of function (of which everything returned from a function is in fact a result) would be an erroneous name.

On 2016-01-27, at 12:09:07, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello all,

I’m going to try and round up a summary of arguments for and against this proposal and my response to them, because I think there is a clear sense in everybody’s mind what Either entails, but that sense differs widely depending on individual interactions with the parts of the proposal. I take full responsibility for the rhetoric and the style of debate that has been going on for the past ~24 hours. It was borderline unprofessional the way this was going and I want to apologize now to those involved for being so very unclear in my reasoning and my rhetoric as to stir up a senseless debate about points we essentially agreed on beforehand. As such, I’ve made some revisions to the proposal, I request that you all please re-read it (at https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md\) before we try again so we can refocus this debate on more productive avenues of discourse.

Throughout this reply I’ve made heavy use of quotes from other replies. Those will appear in purple. Quotes from the proposal will appear in blue.

The type “Either” that we describe in the proposal is a placeholder. I feel that must be emphasized, because there have been arguments about the name. We specifically mention this in the proposal:

The Swift Standard Library will be updated to include a left-biased sum type we have called Either - though other names may be appropriate depending on how the type is implemented.

What we are requesting is a finite-case, here precisely two-case, type that represents two disjoint possibilities. As noted before, this type is often called Result by Swift framework authors and notably the programming language Rust which uses it in place of an exception handling mechanism.

Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain.

There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` has no intuitive meaning whatsoever. It says absolutely nothing about what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result<T> you actually want to define your own enum so you can attach meaning to the value.

You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result<T,E> type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).

We recognize that Result conveys a particular semantics that encourage this type to cross over into the error-handling domain. As noted in the proposal, we don’t want to emphasize this case because a version of this proposal was already rejected for overlapping too heavily with throws. If the community feels that the proposal deserves to be rewritten in a way that re-emphasizes this case and makes that point then I am up for it. But, I request that this not be used as an argument to reduce the genericity of the type - which is to say I don’t wish to see a Result<T> or a Result<T, E : ErrorType> because they reduce the power of the original proposal.

When I use the term genericity, I am not arguing for the naming scheme of the Either we have, I’m arguing for the structure to be kept around as-is. My biggest fear is that a Result with one lobe and an Error is going to be merged rather than the full proposal because this type and the discussion of it outside of here can become too absorbed in the error-handling case. I do not wish to lose the structure of the type we have now, because that structure is precisely what a future Swift could generalize and abstract upon. The name, however, is up for grabs. We offer a list of alternatives at the end of the proposal, if you have any more to suggest please reply to me here and I’ll see about adding them.

At the same time, it has been brought up that Either conveys no immediate useful information. At the time of writing this proposal, we do not believe that to be the case, but we recognize that by naming this Result we can reach a wider audience. At the end of the day the proposal is about merging in a 2-case sum type. We chose Either not because we wanted to see it merged, but precisely because it was so meaning-agnostic. It’s our lorem-ipsum. For those that think we’re trying to merge a Haskell-ism, I can say with complete confidence that no part of TypeLift intended that in the original proposal. Whatever bad taste Haskell may have left in anybody’s mouth, the Either in our proposal is a placeholder for a name to be decided upon by the community. I felt that this was clear from the line

though other names may be appropriate depending on how the type is implemented.

and

In addition, the name `Either` does not lend much to the imagination,
and the use of `Left` and `Right` have the potential to cause confusion to
novices expecting a `Result<T>`

in the original proposal, but I was wrong. I have updated the draft accordingly.

Besides, even if the type in the proposal were to be merged right this very second, “meaningless" names and all, a domain-specific Result type could easily be recovered from it. The same is not true of a type that is immediately domain-specific like the reduced-generic forms of Result. To translate that into the language of Result using Either as a template: If a Result<T, E> were not merged, then it could not be recovered from Result<T> in any meaningful manner. However, a constrained Result<T, E : ErrorType> can be recovered from the fully generic type in the proposal.

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names. Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?

This is in line with the goals of the proposal and I would certainly support this renaming if it serves the community’s best interest. You all are, by now, aware of my qualms with the name, but I’m not one to dwell on these things when we’ve made it clear in the proposal that the type can go by many names. It’s the structure of a sum that we’re after, and we’re willing to take it how it comes - but contingent on the shape of the type not differing from the proposal as written. I request that if the name Result be brought up again, that it come with the specific number and kind of parameters involved so we can nail down the shape being discussed.

The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples. However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements. Your Either type has neither of these features.

Contrary to the impression the other discussion has made, nowhere in the proposal do we wish to augment the type system. If this is done correctly, the type in the proposal should be a ~40-line addition to the standard library, it should not wind up as a full-blown language change. We are not advocating for an n-element sum type, nor are we arguing for a structural typing scheme that would put variadic sums in the language because we recognize that solution is untenable. We are, however, advocating for the inclusion of a 2-case sum type we happen to call Either in writing.

The type system already supports N-ary “either” types. We call them enums.

This is another example of exactly why Either is terrible in practice. I understand that from a type algebra point of view this is perfectly reasonable and clean and that a 2-way sum is all that is necessary because larger sums are easily created by construction. Type theory-wise it’s lovely.

Because this is a non-goal of the type. The sum as presented in the proposal does not attempt to take the place of enums, nor does it make any bones about being a finite entity. We are specifically emphasizing the two-element case. Any other arguments that pertain to its inclusion as a feature of the type system should start at the last site of discussion and probably terminate in a separate proposal adding that kind of scheme to the Swift language itself. We are arguing for a simple change to the standard library, nothing more.

As before, unlike `throws`, a disjoint union type can be applied in arbitrary
positions, used as a member, and easily checked for completeness
at compile time. In addition, the lack of a standard union type has
led the Swift community to create [numerous](https://github.com/search?utf8=✓&q=Either+language%3Aswift <https://github.com/search?utf8=✓&q=Either+language%3Aswift&gt;\) duplicate implementations of the
same mutually incompatible types over and over and over again. In the
interest of promoting a type that there has received clear interest by the
community, the addition to the Standard Library is necessary.

The argument is not “let’s toss out all implementations of 2-case enums in favor of this sum” it’s “very often, when you’ve got a two-case enum with bias, you’ve got a sum described in the proposal”. This pattern shows up in a sufficiently large number of cases that we feel that the standard library deserves to have the final say as to a community-guided implementation of this type because individual implementations seem to differ only in a few minor places like naming or generic positions.

I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.

This is another motivating factor that lines up with a major tenant of the proposal. We would not be suggesting this change to the standard library if we did not see this pattern show up in a number of large frameworks, applications, and everything in between. We offer a section of motivating examples and links that should convince you of its commonality if that is still a sticking point.

I’d say “works”, not works; the ergonomics are terrible, you are unlikely to be able to take advantage of the bias anymore, and even if we overlook all that, you still have to enforce an external convention to get mutual-interoperability at each n; otherwise, you may say Either<Either<,>,Either<,>> but I may say Either<Either<Either<,>,>,> and someone else may say Either<,Either<,Either<,>>> and someone else says Either<,Either<Either<,>,>> and so on…

This point, while valid, is also an unfortunate feature of Optionals as well, which I have argued can be viewed as an Sum with one lobe “sealed” by Top, the empty tuple. I have yet to see a use of a sum type that needs nesting like this, nor have I seen any type or type alias that attempts to use this to recover an n-ary Sum because it just doesn’t happen. If you have a disjoint set of possibilities with order greater than two, as Chris noted, Swift already offers enums. And if such a case has arisen, it needs to be refactored just as Optional<Optional<Optional<...>>> would be.

* An either-like type should be named something meaningful for the context it is used

See above.

* There are a lot of cases where an either-like type is useful, there may generalised functions that are often used on them

See proposal.

* Is defining or re-defining an either type hard?

See proposal.

* Is it too niche to be in the standard library

We don’t believe so, see proposal.

No, I take issue with the entire fundamental idea behind your proposal. You've explicitly defined this type purely by its shape, with no meaning whatsoever given to either variant, except insofar as the type is Left-biased (which only serves to be even more confusing; since there's no actual meaning assigned to Left/Right, what is the justification for adding the left-biasing?)

The rationale given for bias has been updated in the latest draft.

tl;dr

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.

On Jan 20, 2016, at 10:17 PM, Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

So Either as a type is problematic because of a name… or something like that that it is either to generic or too niche…

I was wondering if we could get to it by another way that would be interoperable between libraries but have absolutely no implementation in the general library - but would be able to be tacked on through external libraries.

Something like:

typealias MyEither = Int | String // not sure how it would be done with generic typing.

where Either may contain an Int or a String but not both.

As well as a way for third parties to add on things (queriable somehow) like fold, map as their implementation needs. Maybe also be able to define postfix operators for functions that decompose or use these “Either” types without calling them “Either”.

···

On 2016-01-27, at 12:52:38, Jarod Long via swift-evolution <swift-evolution@swift.org> wrote:

I hadn't, thanks for pointing me in the right direction.

Jarod

On Jan 26, 2016, 21:48 -0800, Developer <devteam.codafi@gmail.com>, wrote:

Have you seen the last round of discussions (root https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\)? I don’t want to continue discussing this specific thing here because it is outside the scope of the proposal as it stands.

On Jan 27, 2016, at 12:46 AM, Jarod Long via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

FWIW, I think a preferable alternative to an Either or Result type is union types, which could work as a sort of on-the-fly enum. Silly example:

func getNameOrAge() -> |String, Int| { // or maybe enum(String, Int)
    if true {
        return "Butterscotch"
    } else {
        return 25
    }
}

switch getNameOrAge() {
    case String(let name): print("Name: \(name)")
    case Int(let age): print("Age: \(age)")
}

I've run into a couple situations where I've needed to return different types from some one-off function (outside of the result/error pattern), but didn't want to create another type for that hyper-specific use case, and I wished I had some way of inlining a one-off, either-or type. It's even temping to use a tuple with optional values to leverage its inlining behavior, but that produces extra unwanted code paths. Union types are a powerful and use-case-agnostic solution to that kind of problem.

Jarod

On Jan 26, 2016, 21:27 -0800, Craig Cruden via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>, wrote:

The other minor point is that this type (TBD) may not in fact be a result of function (of which everything returned from a function is in fact a result) would be an erroneous name.

On 2016-01-27, at 12:09:07, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello all,

I’m going to try and round up a summary of arguments for and against this proposal and my response to them, because I think there is a clear sense in everybody’s mind what Either entails, but that sense differs widely depending on individual interactions with the parts of the proposal. I take full responsibility for the rhetoric and the style of debate that has been going on for the past ~24 hours. It was borderline unprofessional the way this was going and I want to apologize now to those involved for being so very unclear in my reasoning and my rhetoric as to stir up a senseless debate about points we essentially agreed on beforehand. As such, I’ve made some revisions to the proposal, I request that you all please re-read it (at https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md\) before we try again so we can refocus this debate on more productive avenues of discourse.

Throughout this reply I’ve made heavy use of quotes from other replies. Those will appear in purple. Quotes from the proposal will appear in blue.

The type “Either” that we describe in the proposal is a placeholder. I feel that must be emphasized, because there have been arguments about the name. We specifically mention this in the proposal:

The Swift Standard Library will be updated to include a left-biased sum type we have called Either - though other names may be appropriate depending on how the type is implemented.

What we are requesting is a finite-case, here precisely two-case, type that represents two disjoint possibilities. As noted before, this type is often called Result by Swift framework authors and notably the programming language Rust which uses it in place of an exception handling mechanism.

Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain.

There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` has no intuitive meaning whatsoever. It says absolutely nothing about what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result<T> you actually want to define your own enum so you can attach meaning to the value.

You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result<T,E> type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).

We recognize that Result conveys a particular semantics that encourage this type to cross over into the error-handling domain. As noted in the proposal, we don’t want to emphasize this case because a version of this proposal was already rejected for overlapping too heavily with throws. If the community feels that the proposal deserves to be rewritten in a way that re-emphasizes this case and makes that point then I am up for it. But, I request that this not be used as an argument to reduce the genericity of the type - which is to say I don’t wish to see a Result<T> or a Result<T, E : ErrorType> because they reduce the power of the original proposal.

When I use the term genericity, I am not arguing for the naming scheme of the Either we have, I’m arguing for the structure to be kept around as-is. My biggest fear is that a Result with one lobe and an Error is going to be merged rather than the full proposal because this type and the discussion of it outside of here can become too absorbed in the error-handling case. I do not wish to lose the structure of the type we have now, because that structure is precisely what a future Swift could generalize and abstract upon. The name, however, is up for grabs. We offer a list of alternatives at the end of the proposal, if you have any more to suggest please reply to me here and I’ll see about adding them.

At the same time, it has been brought up that Either conveys no immediate useful information. At the time of writing this proposal, we do not believe that to be the case, but we recognize that by naming this Result we can reach a wider audience. At the end of the day the proposal is about merging in a 2-case sum type. We chose Either not because we wanted to see it merged, but precisely because it was so meaning-agnostic. It’s our lorem-ipsum. For those that think we’re trying to merge a Haskell-ism, I can say with complete confidence that no part of TypeLift intended that in the original proposal. Whatever bad taste Haskell may have left in anybody’s mouth, the Either in our proposal is a placeholder for a name to be decided upon by the community. I felt that this was clear from the line

though other names may be appropriate depending on how the type is implemented.

and

In addition, the name `Either` does not lend much to the imagination,
and the use of `Left` and `Right` have the potential to cause confusion to
novices expecting a `Result<T>`

in the original proposal, but I was wrong. I have updated the draft accordingly.

Besides, even if the type in the proposal were to be merged right this very second, “meaningless" names and all, a domain-specific Result type could easily be recovered from it. The same is not true of a type that is immediately domain-specific like the reduced-generic forms of Result. To translate that into the language of Result using Either as a template: If a Result<T, E> were not merged, then it could not be recovered from Result<T> in any meaningful manner. However, a constrained Result<T, E : ErrorType> can be recovered from the fully generic type in the proposal.

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names. Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?

This is in line with the goals of the proposal and I would certainly support this renaming if it serves the community’s best interest. You all are, by now, aware of my qualms with the name, but I’m not one to dwell on these things when we’ve made it clear in the proposal that the type can go by many names. It’s the structure of a sum that we’re after, and we’re willing to take it how it comes - but contingent on the shape of the type not differing from the proposal as written. I request that if the name Result be brought up again, that it come with the specific number and kind of parameters involved so we can nail down the shape being discussed.

The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples. However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements. Your Either type has neither of these features.

Contrary to the impression the other discussion has made, nowhere in the proposal do we wish to augment the type system. If this is done correctly, the type in the proposal should be a ~40-line addition to the standard library, it should not wind up as a full-blown language change. We are not advocating for an n-element sum type, nor are we arguing for a structural typing scheme that would put variadic sums in the language because we recognize that solution is untenable. We are, however, advocating for the inclusion of a 2-case sum type we happen to call Either in writing.

The type system already supports N-ary “either” types. We call them enums.

This is another example of exactly why Either is terrible in practice. I understand that from a type algebra point of view this is perfectly reasonable and clean and that a 2-way sum is all that is necessary because larger sums are easily created by construction. Type theory-wise it’s lovely.

Because this is a non-goal of the type. The sum as presented in the proposal does not attempt to take the place of enums, nor does it make any bones about being a finite entity. We are specifically emphasizing the two-element case. Any other arguments that pertain to its inclusion as a feature of the type system should start at the last site of discussion and probably terminate in a separate proposal adding that kind of scheme to the Swift language itself. We are arguing for a simple change to the standard library, nothing more.

As before, unlike `throws`, a disjoint union type can be applied in arbitrary
positions, used as a member, and easily checked for completeness
at compile time. In addition, the lack of a standard union type has
led the Swift community to create [numerous](https://github.com/search?utf8=✓&q=Either+language%3Aswift <https://github.com/search?utf8=✓&q=Either+language%3Aswift&gt;\) duplicate implementations of the
same mutually incompatible types over and over and over again. In the
interest of promoting a type that there has received clear interest by the
community, the addition to the Standard Library is necessary.

The argument is not “let’s toss out all implementations of 2-case enums in favor of this sum” it’s “very often, when you’ve got a two-case enum with bias, you’ve got a sum described in the proposal”. This pattern shows up in a sufficiently large number of cases that we feel that the standard library deserves to have the final say as to a community-guided implementation of this type because individual implementations seem to differ only in a few minor places like naming or generic positions.

I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.

This is another motivating factor that lines up with a major tenant of the proposal. We would not be suggesting this change to the standard library if we did not see this pattern show up in a number of large frameworks, applications, and everything in between. We offer a section of motivating examples and links that should convince you of its commonality if that is still a sticking point.

I’d say “works”, not works; the ergonomics are terrible, you are unlikely to be able to take advantage of the bias anymore, and even if we overlook all that, you still have to enforce an external convention to get mutual-interoperability at each n; otherwise, you may say Either<Either<,>,Either<,>> but I may say Either<Either<Either<,>,>,> and someone else may say Either<,Either<,Either<,>>> and someone else says Either<,Either<Either<,>,>> and so on…

This point, while valid, is also an unfortunate feature of Optionals as well, which I have argued can be viewed as an Sum with one lobe “sealed” by Top, the empty tuple. I have yet to see a use of a sum type that needs nesting like this, nor have I seen any type or type alias that attempts to use this to recover an n-ary Sum because it just doesn’t happen. If you have a disjoint set of possibilities with order greater than two, as Chris noted, Swift already offers enums. And if such a case has arisen, it needs to be refactored just as Optional<Optional<Optional<...>>> would be.

* An either-like type should be named something meaningful for the context it is used

See above.

* There are a lot of cases where an either-like type is useful, there may generalised functions that are often used on them

See proposal.

* Is defining or re-defining an either type hard?

See proposal.

* Is it too niche to be in the standard library

We don’t believe so, see proposal.

No, I take issue with the entire fundamental idea behind your proposal. You've explicitly defined this type purely by its shape, with no meaning whatsoever given to either variant, except insofar as the type is Left-biased (which only serves to be even more confusing; since there's no actual meaning assigned to Left/Right, what is the justification for adding the left-biasing?)

The rationale given for bias has been updated in the latest draft.

tl;dr

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.

On Jan 20, 2016, at 10:17 PM, Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:

Hey all,

Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).

https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples

~Robert Widmann

2016/01/09 14:19、Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> のメッセージ:

Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. The proposal can be found here (Either by CodaFi · Pull Request #67 · apple/swift-evolution · GitHub) and a link to the root our previous round of discussion is here (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html\).

Thanks all!

~Robert Widmann

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution