Proposal: An Either Type in the STL

Evolution Discussion
21

Or the Swift Common Module? SCM

···

On Mon, Dec 14, 2015 at 8:21 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote:

How about the Swift Standard Library (SSL)? ;-)

On Mon, Dec 14, 2015 at 1:06 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution < >> swift-evolution@swift.org> wrote:

It’s high time the STL admitted some kind of disjoint union type…

Friends,

The STL <https://en.wikipedia.org/wiki/Standard_Template_Library&gt; is a
hugely influential and important effort, but it is not the Swift standard
library. We don't want to be seen as either co-opting the name or taking
credit for its design, nor do we want to sell short the unique strengths of
Swift's own standard library by letting it be confused with that other body
of work. My humble request is that, if we want to use a short name to
refer to the Swift standard library, we choose a different one. "Stdlib"
seems workable and precedented in our source directory layout, for example.

Thanks,
-Dave

_______________________________________________
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

22

I support the addition of a Result, and I encourage people to look at std::result - Rust for a good example of how this can be done well. I'd like a Result<T,E> in Swift that looks similar.

I do not support the addition of Either. As far as I am aware, the only
compelling argument in favor of an Either type is "because Haskell has
one", but I believe it's commonly recognized that Haskell's Either is
not particularly good. It's a weird name for results (which Result
covers), and for other cases it's usually better just to define your own
two-variant enum anyway. Rust provides some evidence in favor of this,
as this was the rationale for why Rust has a Result<T,E> but no Either,
and it turns out there has been no need to add an Either.

-Kevin Ballard

I hope that we can get both Either and Result into the standard lib. A
great situation might be if Result were some sort of newtype
declaration of Either.

There is! That’s what the Bifunctor typeclass is for. But if you
had to pick just one of them to implement some Functor constraint -
some canonical `map` function, would you pick the side that you
filled with Errors, or the side that you filled with Values?

Is there not precedent for having both "mapLeft<T>(f: L -> T) ->
Either<T, R>" and "mapRight<T>(f: R -> T) -> Either<L, T>" ?

Jacob Bandes-Storch

How would you write `map` for an unbiased Either. You have to pick
a side!

Our implementation happens to be the one standardized on by Scala,
Haskell, ML, (and to a limited extent) F#. For a less arbitrary
reason, the use of "Right as Correct" is because Either, in all
it’s Bifunctor-ial ways, has to admit two ways to map “across”
itself. To paraphrase the words of a friend "There are lots of
things in computer science we can leftMap”. In Haskell, such a
thing is represented by the Functor typeclass, and due to the way
type application works in that language, the convention has been to
map over the rightmost side. But this isn’t Haskell, so our
reasons can get even more theoretical than that (if you really want
to get into what it looks like when you implement Covariant mapping
down the left side of a common Bifunctor like Either, Cats has
already had a thorough discussion on the subject:
Issues · non/cats · GitHub).

I’m sorry, I misunderstood. I guess an enum would be the
appropriate choice, instead.

As far as left/right goes, the decision to have left or right be
the “correct” value is entirely arbitrary and should be left up to
the developer. It should be a convention at best.

Ilias

With a tuple, you have to do “(left: T?, right: U?)”, whereas
with an Either you are guaranteed to always have one or other
other; never both and never neither. That is not guaranteed with
the tuple.

Dave

What are the advantage over using a tuple? One great feature
about tuples is being able to name parameters so you can dispel
ambiguity.

The idea of using Left/Right is to remain agnostic to what
sorts of things users might want to put in. It's feasible a
user might want Either<Int, String>, not just Either<ErrorType,
>.

While I'm not sure Left & Right are the best choices, I don't
think it's particularly worrisome when it comes to errors, as
the general type-safety of the language will prevent users from
mixing up success & error cases.

Jacob

Hi Robert,

I agree with your recommendation of a generic Either type.

However, I find your use of “Right” as the “Correct” value
(whatever that means) of an instance of an Either type a
little perplexing. While clever, it is exactly the kind of
convention that easily leads to misunderstandings about the
nature of the type itself ie. is it right and left or wrong
and correct? At least that is my first impression after
scanning your code.

Ilias

>
> It’s high time the STL admitted some kind of disjoint union
> type, at the very least because it’s such a minor addition
> it seems a shame to leave it out. Whatever feelings one may
> have about `throws`, the lack of standardizing on a datatype
> representing choice has caused the community to get creative
> and create many disjoint implementation of the same concept
> over and over and over again. To that end, I propose the
> STL ship with an Either type; We at TypeLift have already
> got our own we’d like to model it on
> (https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16\)
> .
>
>
> ~Robert Widmann (CodaFi)
> _______________________________________________
> 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

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

_______________________________________________

swift-evolution mailing list

···

On Wed, Dec 9, 2015, at 04:01 PM, T.J. Usiyan via swift-evolution wrote:

On Thu, Dec 10, 2015 at 5:25 AM, Developer via swift-evolution <swift- > evolution@swift.org> wrote:

On Dec 9, 2015, at 6:52 PM, Jacob Bandes-Storch <jtbandes@gmail.com> >>> wrote:
On Wed, Dec 9, 2015 at 3:49 PM, Developer <devteam.codafi@gmail.com> >>> wrote:

On Dec 9, 2015, at 6:44 PM, Ilias Karim <ilias.karim@gmail.com> >>>>> wrote:

On Dec 9, 2015, at 3:43 PM, Dave DeLong <delong@apple.com> wrote:

On Dec 9, 2015, at 4:41 PM, Ilias Karim via swift-evolution <swift- >>>>>>> evolution@swift.org> wrote:

On Dec 9, 2015, at 3:35 PM, Jacob Bandes-Storch >>>>>>>> <jtbandes@gmail.com> wrote:
On Wed, Dec 9, 2015 at 3:32 PM, Ilias Karim via swift-evolution<swift- >>>>>>>> evolution@swift.org>wrote:

> On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution >>>>>>>>> > <swift-evolution@swift.org> wrote:

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

23

Can you explain why you think it's better to just define your own
two-variant enum rather than having a built-in Either type, or point me to
the evidence that Rust found in favor of this approach?

I had to create my own Either type for some code I wrote semi-recently and
wished it was built in, so I'm wondering why I apparently shouldn't have
wished that, but been glad that I'm creating my own.

···

On Thu, Dec 10, 2015 at 1:34 AM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote:

I support the addition of a Result, and I encourage people to look at
https://doc.rust-lang.org/stable/std/result/index.html for a good example
of how this can be done well. I'd like a Result<T,E> in Swift that looks
similar.

I do not support the addition of Either. As far as I am aware, the only
compelling argument in favor of an Either type is "because Haskell has
one", but I believe it's commonly recognized that Haskell's Either is not
particularly good. It's a weird name for results (which Result covers), and
for other cases it's usually better just to define your own two-variant
enum anyway. Rust provides some evidence in favor of this, as this was the
rationale for why Rust has a Result<T,E> but no Either, and it turns out
there has been no need to add an Either.

-Kevin Ballard

On Wed, Dec 9, 2015, at 04:01 PM, T.J. Usiyan via swift-evolution wrote:

I hope that we can get both Either and Result into the standard lib. A
great situation might be if Result were some sort of newtype declaration of
Either.

On Thu, Dec 10, 2015 at 5:25 AM, Developer via swift-evolution < > swift-evolution@swift.org> wrote:

There is! That’s what the Bifunctor typeclass is for. But if you had to
pick just one of them to implement some Functor constraint - some canonical
`map` function, would you pick the side that you filled with Errors, or the
side that you filled with Values?

On Dec 9, 2015, at 6:52 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

Is there not precedent for having both "mapLeft<T>(f: L -> T) -> Either<T,
>" and "mapRight<T>(f: R -> T) -> Either<L, T>" ?

Jacob Bandes-Storch

On Wed, Dec 9, 2015 at 3:49 PM, Developer <devteam.codafi@gmail.com> > wrote:

How would you write `map` for an unbiased Either. You have to pick a side!

Our implementation happens to be the one standardized on by Scala,
Haskell, ML, (and to a limited extent) F#. For a less arbitrary reason,
the use of "Right as Correct" is because Either, in all it’s Bifunctor-ial
ways, has to admit two ways to map “across” itself. To paraphrase the
words of a friend "There are lots of things in computer science we can
leftMap”. In Haskell, such a thing is represented by the Functor
typeclass, and due to the way type application works in that language, the
convention has been to map over the rightmost side. But this isn’t
Haskell, so our reasons can get even more theoretical than that (if you
really want to get into what it looks like when you implement Covariant
mapping down the left side of a common Bifunctor like Either, Cats has
already had a thorough discussion on the subject:
Issues · non/cats · GitHub).

On Dec 9, 2015, at 6:44 PM, Ilias Karim <ilias.karim@gmail.com> wrote:

I’m sorry, I misunderstood. I guess an enum would be the appropriate
choice, instead.

As far as left/right goes, the decision to have left or right be the
“correct” value is entirely arbitrary and should be left up to the
developer. It should be a convention at best.

Ilias

On Dec 9, 2015, at 3:43 PM, Dave DeLong <delong@apple.com> wrote:

With a tuple, you have to do “(left: T?, right: U?)”, whereas with an
Either you are guaranteed to always have one or other other; never both and
never neither. That is not guaranteed with the tuple.

Dave

On Dec 9, 2015, at 4:41 PM, Ilias Karim via swift-evolution < > swift-evolution@swift.org> wrote:

What are the advantage over using a tuple? One great feature about tuples
is being able to name parameters so you can dispel ambiguity.

On Dec 9, 2015, at 3:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:

The idea of using Left/Right is to remain agnostic to what sorts of things
users might want to put in. It's feasible a user might want Either<Int,
>, not just Either<ErrorType, T>.

While I'm not sure Left & Right are the best choices, I don't think it's
particularly worrisome when it comes to errors, as the general type-safety
of the language will prevent users from mixing up success & error cases.

Jacob

On Wed, Dec 9, 2015 at 3:32 PM, Ilias Karim via swift-evolution< > swift-evolution@swift.org>wrote:

Hi Robert,

I agree with your recommendation of a generic Either type.

However, I find your use of “Right” as the “Correct” value (whatever that
means) of an instance of an Either type a little perplexing. While clever,
it is exactly the kind of convention that easily leads to misunderstandings
about the nature of the type itself ie. is it right and left or wrong and
correct? At least that is my first impression after scanning your code.

Ilias

> On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution < > swift-evolution@swift.org> wrote:
>
> It’s high time the STL admitted some kind of disjoint union type, at the
very least because it’s such a minor addition it seems a shame to leave it
out. Whatever feelings one may have about `throws`, the lack of
standardizing on a datatype representing choice has caused the community to
get creative and create many disjoint implementation of the same concept
over and over and over again. To that end, I propose the STL ship with an
Either type; We at TypeLift have already got our own we’d like to model it
on (https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16
).
>
>
> ~Robert Widmann (CodaFi)
> _______________________________________________
> 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

_______________________________________________
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

*_______________________________________________*
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

24

As an alternative to a semantically-neutral Either type, it might be worth considering the possibility of anonymous structural sum types (similar to how tuples are the structural analog of structs).

-Joe

···

On Dec 10, 2015, at 10:06 AM, Nick Shelley via swift-evolution <swift-evolution@swift.org> wrote:

Can you explain why you think it's better to just define your own two-variant enum rather than having a built-in Either type, or point me to the evidence that Rust found in favor of this approach?

I had to create my own Either type for some code I wrote semi-recently and wished it was built in, so I'm wondering why I apparently shouldn't have wished that, but been glad that I'm creating my own.

On Thu, Dec 10, 2015 at 1:34 AM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I support the addition of a Result, and I encourage people to look at std::result - Rust for a good example of how this can be done well. I'd like a Result<T,E> in Swift that looks similar.

I do not support the addition of Either. As far as I am aware, the only compelling argument in favor of an Either type is "because Haskell has one", but I believe it's commonly recognized that Haskell's Either is not particularly good. It's a weird name for results (which Result covers), and for other cases it's usually better just to define your own two-variant enum anyway. Rust provides some evidence in favor of this, as this was the rationale for why Rust has a Result<T,E> but no Either, and it turns out there has been no need to add an Either.

-Kevin Ballard

On Wed, Dec 9, 2015, at 04:01 PM, T.J. Usiyan via swift-evolution wrote:

I hope that we can get both Either and Result into the standard lib. A great situation might be if Result were some sort of newtype declaration of Either.

On Thu, Dec 10, 2015 at 5:25 AM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
There is! That’s what the Bifunctor typeclass is for. But if you had to pick just one of them to implement some Functor constraint - some canonical `map` function, would you pick the side that you filled with Errors, or the side that you filled with Values?

On Dec 9, 2015, at 6:52 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Is there not precedent for having both "mapLeft<T>(f: L -> T) -> Either<T, R>" and "mapRight<T>(f: R -> T) -> Either<L, T>" ?

Jacob Bandes-Storch

On Wed, Dec 9, 2015 at 3:49 PM, Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:
How would you write `map` for an unbiased Either. You have to pick a side!

Our implementation happens to be the one standardized on by Scala, Haskell, ML, (and to a limited extent) F#. For a less arbitrary reason, the use of "Right as Correct" is because Either, in all it’s Bifunctor-ial ways, has to admit two ways to map “across” itself. To paraphrase the words of a friend "There are lots of things in computer science we can leftMap”. In Haskell, such a thing is represented by the Functor typeclass, and due to the way type application works in that language, the convention has been to map over the rightmost side. But this isn’t Haskell, so our reasons can get even more theoretical than that (if you really want to get into what it looks like when you implement Covariant mapping down the left side of a common Bifunctor like Either, Cats has already had a thorough discussion on the subject: Issues · non/cats · GitHub).

On Dec 9, 2015, at 6:44 PM, Ilias Karim <ilias.karim@gmail.com <mailto:ilias.karim@gmail.com>> wrote:

I’m sorry, I misunderstood. I guess an enum would be the appropriate choice, instead.

As far as left/right goes, the decision to have left or right be the “correct” value is entirely arbitrary and should be left up to the developer. It should be a convention at best.

Ilias

On Dec 9, 2015, at 3:43 PM, Dave DeLong <delong@apple.com <mailto:delong@apple.com>> wrote:

With a tuple, you have to do “(left: T?, right: U?)”, whereas with an Either you are guaranteed to always have one or other other; never both and never neither. That is not guaranteed with the tuple.

Dave

On Dec 9, 2015, at 4:41 PM, Ilias Karim via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What are the advantage over using a tuple? One great feature about tuples is being able to name parameters so you can dispel ambiguity.

On Dec 9, 2015, at 3:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

The idea of using Left/Right is to remain agnostic to what sorts of things users might want to put in. It's feasible a user might want Either<Int, String>, not just Either<ErrorType, T>.

While I'm not sure Left & Right are the best choices, I don't think it's particularly worrisome when it comes to errors, as the general type-safety of the language will prevent users from mixing up success & error cases.

Jacob

On Wed, Dec 9, 2015 at 3:32 PM, Ilias Karim via swift-evolution<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote:
Hi Robert,

I agree with your recommendation of a generic Either type.

However, I find your use of “Right” as the “Correct” value (whatever that means) of an instance of an Either type a little perplexing. While clever, it is exactly the kind of convention that easily leads to misunderstandings about the nature of the type itself ie. is it right and left or wrong and correct? At least that is my first impression after scanning your code.

Ilias

> On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It’s high time the STL admitted some kind of disjoint union type, at the very least because it’s such a minor addition it seems a shame to leave it out. Whatever feelings one may have about `throws`, the lack of standardizing on a datatype representing choice has caused the community to get creative and create many disjoint implementation of the same concept over and over and over again. To that end, I propose the STL ship with an Either type; We at TypeLift have already got our own we’d like to model it on (https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16\).
>
>
> ~Robert Widmann (CodaFi)
> _______________________________________________
> 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 <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

25

The simplest argument is that the name Either (and variants Left and
Right) are so generic as to be meaningless, and there's no good
alternatives that are any better. By defining your own enum, you get to
name the enum and its variants (and document them) in a way that's
actually meaningful.

If you want to use the Either type in a context that actually is pretty
generic (such that you can't come up with other names that are
particularly meaningful), which I'd suggest is pretty rare (nothing
immediately comes to mind that is really this generic), by using the stdlib-
provided Either type you're also restricting yourself to only ever
having 2 variants. If you find a need for a 3rd variant later (for
example, if you have a function that takes two values and it returns one
of them, and you later realize you want an overload that takes 3
values), then you can't add it to Either and have to create your own
enum anyway. By starting off with your own enum you make it a lot easier
to update code for the 3rd variant (only exhaustive switches are forced
to change, everything else is source-compatible).

Ultimately, given how trivial it is to define a new enum, there's just
no real compelling reason to have a stdlib-defined Either. The best
argument I can come up with in favor of using Either instead of your own
enum is that the stdlib may have already defined methods like mapLeft()
and mapRight() on Either, but I don't find that to be a very good
reason. In most cases those methods are not particularly helpful.

Also, in my personal experience, in what (admittedly small) amount of
Haskell code I've seen, every single instance of Either was being used
for error handling, and Result already handles that job. Every other
case of a two-variant data I've seen in Haskell that wasn't error
handling, it was a custom data instead of Either. And as I already
stated, Rust made the decision here to have Result and nothing else, and
there's been no push to add an Either type to the stdlib (I don't think
I've even seen it so much as suggested ever since Result was added,
although I haven't been paying as much attention to Rust since 1.0 came
out so I can't say that definitively).

-Kevin Ballard

···

On Thu, Dec 10, 2015, at 10:06 AM, Nick Shelley wrote:

Can you explain why you think it's better to just define your own two-
variant enum rather than having a built-in Either type, or point me to
the evidence that Rust found in favor of this approach?

I had to create my own Either type for some code I wrote semi-recently
and wished it was built in, so I'm wondering why I apparently
shouldn't have wished that, but been glad that I'm creating my own.

26

As an alternative to a semantically-neutral Either type, it might be worth considering the possibility of anonymous structural sum types (similar to how tuples are the structural analog of structs).

John mentioned that these are a massive complication for type systems when I proposed them as a possible way to implement throwing multiple error types. Do you agree with that?

···

On Dec 10, 2015, at 10:06 AM, Nick Shelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Can you explain why you think it's better to just define your own two-variant enum rather than having a built-in Either type, or point me to the evidence that Rust found in favor of this approach?

I had to create my own Either type for some code I wrote semi-recently and wished it was built in, so I'm wondering why I apparently shouldn't have wished that, but been glad that I'm creating my own.

On Thu, Dec 10, 2015 at 1:34 AM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I support the addition of a Result, and I encourage people to look at std::result - Rust for a good example of how this can be done well. I'd like a Result<T,E> in Swift that looks similar.

I do not support the addition of Either. As far as I am aware, the only compelling argument in favor of an Either type is "because Haskell has one", but I believe it's commonly recognized that Haskell's Either is not particularly good. It's a weird name for results (which Result covers), and for other cases it's usually better just to define your own two-variant enum anyway. Rust provides some evidence in favor of this, as this was the rationale for why Rust has a Result<T,E> but no Either, and it turns out there has been no need to add an Either.

-Kevin Ballard

On Wed, Dec 9, 2015, at 04:01 PM, T.J. Usiyan via swift-evolution wrote:

I hope that we can get both Either and Result into the standard lib. A great situation might be if Result were some sort of newtype declaration of Either.

On Thu, Dec 10, 2015 at 5:25 AM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
There is! That’s what the Bifunctor typeclass is for. But if you had to pick just one of them to implement some Functor constraint - some canonical `map` function, would you pick the side that you filled with Errors, or the side that you filled with Values?

On Dec 9, 2015, at 6:52 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Is there not precedent for having both "mapLeft<T>(f: L -> T) -> Either<T, R>" and "mapRight<T>(f: R -> T) -> Either<L, T>" ?

Jacob Bandes-Storch

On Wed, Dec 9, 2015 at 3:49 PM, Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:
How would you write `map` for an unbiased Either. You have to pick a side!

Our implementation happens to be the one standardized on by Scala, Haskell, ML, (and to a limited extent) F#. For a less arbitrary reason, the use of "Right as Correct" is because Either, in all it’s Bifunctor-ial ways, has to admit two ways to map “across” itself. To paraphrase the words of a friend "There are lots of things in computer science we can leftMap”. In Haskell, such a thing is represented by the Functor typeclass, and due to the way type application works in that language, the convention has been to map over the rightmost side. But this isn’t Haskell, so our reasons can get even more theoretical than that (if you really want to get into what it looks like when you implement Covariant mapping down the left side of a common Bifunctor like Either, Cats has already had a thorough discussion on the subject: Issues · non/cats · GitHub).

On Dec 9, 2015, at 6:44 PM, Ilias Karim <ilias.karim@gmail.com <mailto:ilias.karim@gmail.com>> wrote:

I’m sorry, I misunderstood. I guess an enum would be the appropriate choice, instead.

As far as left/right goes, the decision to have left or right be the “correct” value is entirely arbitrary and should be left up to the developer. It should be a convention at best.

Ilias

On Dec 9, 2015, at 3:43 PM, Dave DeLong <delong@apple.com <mailto:delong@apple.com>> wrote:

With a tuple, you have to do “(left: T?, right: U?)”, whereas with an Either you are guaranteed to always have one or other other; never both and never neither. That is not guaranteed with the tuple.

Dave

On Dec 9, 2015, at 4:41 PM, Ilias Karim via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What are the advantage over using a tuple? One great feature about tuples is being able to name parameters so you can dispel ambiguity.

On Dec 9, 2015, at 3:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

The idea of using Left/Right is to remain agnostic to what sorts of things users might want to put in. It's feasible a user might want Either<Int, String>, not just Either<ErrorType, T>.

While I'm not sure Left & Right are the best choices, I don't think it's particularly worrisome when it comes to errors, as the general type-safety of the language will prevent users from mixing up success & error cases.

Jacob

On Wed, Dec 9, 2015 at 3:32 PM, Ilias Karim via swift-evolution<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote:
Hi Robert,

I agree with your recommendation of a generic Either type.

However, I find your use of “Right” as the “Correct” value (whatever that means) of an instance of an Either type a little perplexing. While clever, it is exactly the kind of convention that easily leads to misunderstandings about the nature of the type itself ie. is it right and left or wrong and correct? At least that is my first impression after scanning your code.

Ilias

> On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It’s high time the STL admitted some kind of disjoint union type, at the very least because it’s such a minor addition it seems a shame to leave it out. Whatever feelings one may have about `throws`, the lack of standardizing on a datatype representing choice has caused the community to get creative and create many disjoint implementation of the same concept over and over and over again. To that end, I propose the STL ship with an Either type; We at TypeLift have already got our own we’d like to model it on (https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16\).
>
>
> ~Robert Widmann (CodaFi)
> _______________________________________________
> 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 <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 <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

27

There are definitely problems if you expect them to behave like unions (so that the type `T + T` == `T`) or be unordered (so that `T + U` == `U + T`), which would be intuitively expected.

-Joe

···

On Dec 10, 2015, at 10:34 AM, Matthew Johnson <matthew@anandabits.com> wrote:

As an alternative to a semantically-neutral Either type, it might be worth considering the possibility of anonymous structural sum types (similar to how tuples are the structural analog of structs).

John mentioned that these are a massive complication for type systems when I proposed them as a possible way to implement throwing multiple error types. Do you agree with that?

28

The simplest argument is that the name Either (and variants Left and
Right) are so generic as to be meaningless, and there's no good
alternatives that are any better. By defining your own enum, you get to
name the enum and its variants (and document them) in a way that's actually
meaningful.

If you want to use the Either type in a context that actually is pretty
generic (such that you can't come up with other names that are particularly
meaningful), which I'd suggest is pretty rare (nothing immediately comes to
mind that is really this generic), by using the stdlib-provided Either type
you're also restricting yourself to only ever having 2 variants. If you
find a need for a 3rd variant later (for example, if you have a function
that takes two values and it returns one of them, and you later realize you
want an overload that takes 3 values), then you can't add it to Either and
have to create your own enum anyway. By starting off with your own enum you
make it a lot easier to update code for the 3rd variant (only exhaustive
switches are forced to change, everything else is source-compatible).

Ultimately, given how trivial it is to define a new enum, there's just no
real compelling reason to have a stdlib-defined Either. The best argument I
can come up with in favor of using Either instead of your own enum is that
the stdlib may have already defined methods like mapLeft() and mapRight()
on Either, but I don't find that to be a very good reason. In most cases
those methods are not particularly helpful.

Also, in my personal experience, in what (admittedly small) amount of
Haskell code I've seen, every single instance of Either was being used for
error handling, and Result already handles that job. Every other case of a
two-variant data I've seen in Haskell that wasn't error handling, it was a
custom data instead of Either. And as I already stated, Rust made the
decision here to have Result and nothing else, and there's been no push to
add an Either type to the stdlib (I don't think I've even seen it so much
as suggested ever since Result was added, although I haven't been paying as
much attention to Rust since 1.0 came out so I can't say that definitively).

Thanks for explaining your reasoning, Kevin.

···

On Thu, Dec 10, 2015 at 12:25 PM, Kevin Ballard <kevin@sb.org> wrote:

On Thu, Dec 10, 2015, at 10:06 AM, Nick Shelley wrote:

Can you explain why you think it's better to just define your own
two-variant enum rather than having a built-in Either type, or point me to
the evidence that Rust found in favor of this approach?

I had to create my own Either type for some code I wrote semi-recently and
wished it was built in, so I'm wondering why I apparently shouldn't have
wished that, but been glad that I'm creating my own.

The simplest argument is that the name Either (and variants Left and
Right) are so generic as to be meaningless, and there's no good
alternatives that are any better. By defining your own enum, you get to
name the enum and its variants (and document them) in a way that's actually
meaningful.

If you want to use the Either type in a context that actually is pretty
generic (such that you can't come up with other names that are particularly
meaningful), which I'd suggest is pretty rare (nothing immediately comes to
mind that is really this generic), by using the stdlib-provided Either type
you're also restricting yourself to only ever having 2 variants. If you
find a need for a 3rd variant later (for example, if you have a function
that takes two values and it returns one of them, and you later realize you
want an overload that takes 3 values), then you can't add it to Either and
have to create your own enum anyway. By starting off with your own enum you
make it a lot easier to update code for the 3rd variant (only exhaustive
switches are forced to change, everything else is source-compatible).

Ultimately, given how trivial it is to define a new enum, there's just no
real compelling reason to have a stdlib-defined Either. The best argument I
can come up with in favor of using Either instead of your own enum is that
the stdlib may have already defined methods like mapLeft() and mapRight()
on Either, but I don't find that to be a very good reason. In most cases
those methods are not particularly helpful.

Also, in my personal experience, in what (admittedly small) amount of
Haskell code I've seen, every single instance of Either was being used for
error handling, and Result already handles that job. Every other case of a
two-variant data I've seen in Haskell that wasn't error handling, it was a
custom data instead of Either. And as I already stated, Rust made the
decision here to have Result and nothing else, and there's been no push to
add an Either type to the stdlib (I don't think I've even seen it so much
as suggested ever since Result was added, although I haven't been paying as
much attention to Rust since 1.0 came out so I can't say that definitively).

-Kevin Ballard

29

There are definitely problems if you expect them to behave like unions (so that the type `T + T` == `T`) or be unordered (so that `T + U` == `U + T`), which would be intuitively expected.

Thanks for explaining the source of complication. These definitely seem like intuitively expected behaviors.

In the context of typed throws we would expect ()->() throws MyError, YourError to be the same as ()->() throws YourError, MyError.

I have an idea that seems obvious enough that there are probably problems with it. Couldn't the type system support a canonical subset of the theoretically possible structural sum types and canonicalize structural sum types immediately when it encounters them? An obvious way to canonicalize would be to sort the types (comparator could be arbitrary as long as it was consistent) and then unique adjacent members. This seems like it would provide the intuitively expected behavior. Is this a viable approach or are there problems with it?

Matthew

30

As an alternative to a semantically-neutral Either type, it might be worth considering the possibility of anonymous structural sum types (similar to how tuples are the structural analog of structs).

John mentioned that these are a massive complication for type systems when I proposed them as a possible way to implement throwing multiple error types. Do you agree with that?

There are definitely problems if you expect them to behave like unions (so that the type `T + T` == `T`) or be unordered (so that `T + U` == `U + T`), which would be intuitively expected.

FWIW I like the idea of e.g. "structural sum types” in the language, but if e.g. Swift 3 allows this kind of thing:

extension Foo: Baz where Foo.Bar: Baz {
}

…it is then possible to write sufficiently-useful, adequately-general Sum2, Sum3, etc., types without further language-level support (yes it’s tedious but it’s also a one-off cost).

Given that, language-level support would then seem justified only if there's a very strong sentiment that such types are, say, the right way to design APIs in Swift (which I don’t agree with, and doesn’t seem to to be the community feeling right now, either).

Also FWIW explicit or implicit “proper” unions feel like something I’d be willing to deal with but wouldn’t want to use when at all avoidable.

···

On Dec 10, 2015, at 12:38 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2015, at 10:34 AM, Matthew Johnson <matthew@anandabits.com> wrote:

-Joe

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

31

If the analogy is to tuples, though, I would intuitively expect the other behaviour. Maybe something like:

let listOfProducts: [(Int, Bool)] = [(1, true), (2, false)]
let listOfSums: [(Int|Bool)] = [(|true), (2|)]

···

On 10 Dec 2015, at 18:38, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2015, at 10:34 AM, Matthew Johnson <matthew@anandabits.com> wrote:

As an alternative to a semantically-neutral Either type, it might be worth considering the possibility of anonymous structural sum types (similar to how tuples are the structural analog of structs).

John mentioned that these are a massive complication for type systems when I proposed them as a possible way to implement throwing multiple error types. Do you agree with that?

There are definitely problems if you expect them to behave like unions (so that the type `T + T` == `T`) or be unordered (so that `T + U` == `U + T`), which would be intuitively expected.

-Joe

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

32

Ceylon has lots of experience with a type system built around union and intersection types. Their type checker has been factored into a module, so you could check that out for ideas how they solved these problems (Apache 2.0 license).

-Thorsten

···

Am 10.12.2015 um 19:34 schrieb Matthew Johnson via swift-evolution <swift-evolution@swift.org>:

As an alternative to a semantically-neutral Either type, it might be worth considering the possibility of anonymous structural sum types (similar to how tuples are the structural analog of structs).

John mentioned that these are a massive complication for type systems when I proposed them as a possible way to implement throwing multiple error types. Do you agree with that?

On Dec 10, 2015, at 10:06 AM, Nick Shelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Can you explain why you think it's better to just define your own two-variant enum rather than having a built-in Either type, or point me to the evidence that Rust found in favor of this approach?

I had to create my own Either type for some code I wrote semi-recently and wished it was built in, so I'm wondering why I apparently shouldn't have wished that, but been glad that I'm creating my own.

On Thu, Dec 10, 2015 at 1:34 AM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I support the addition of a Result, and I encourage people to look at std::result - Rust for a good example of how this can be done well. I'd like a Result<T,E> in Swift that looks similar.

I do not support the addition of Either. As far as I am aware, the only compelling argument in favor of an Either type is "because Haskell has one", but I believe it's commonly recognized that Haskell's Either is not particularly good. It's a weird name for results (which Result covers), and for other cases it's usually better just to define your own two-variant enum anyway. Rust provides some evidence in favor of this, as this was the rationale for why Rust has a Result<T,E> but no Either, and it turns out there has been no need to add an Either.

-Kevin Ballard

On Wed, Dec 9, 2015, at 04:01 PM, T.J. Usiyan via swift-evolution wrote:

I hope that we can get both Either and Result into the standard lib. A great situation might be if Result were some sort of newtype declaration of Either.

On Thu, Dec 10, 2015 at 5:25 AM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
There is! That’s what the Bifunctor typeclass is for. But if you had to pick just one of them to implement some Functor constraint - some canonical `map` function, would you pick the side that you filled with Errors, or the side that you filled with Values?

On Dec 9, 2015, at 6:52 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

Is there not precedent for having both "mapLeft<T>(f: L -> T) -> Either<T, R>" and "mapRight<T>(f: R -> T) -> Either<L, T>" ?

Jacob Bandes-Storch

On Wed, Dec 9, 2015 at 3:49 PM, Developer <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>> wrote:
How would you write `map` for an unbiased Either. You have to pick a side!

Our implementation happens to be the one standardized on by Scala, Haskell, ML, (and to a limited extent) F#. For a less arbitrary reason, the use of "Right as Correct" is because Either, in all it’s Bifunctor-ial ways, has to admit two ways to map “across” itself. To paraphrase the words of a friend "There are lots of things in computer science we can leftMap”. In Haskell, such a thing is represented by the Functor typeclass, and due to the way type application works in that language, the convention has been to map over the rightmost side. But this isn’t Haskell, so our reasons can get even more theoretical than that (if you really want to get into what it looks like when you implement Covariant mapping down the left side of a common Bifunctor like Either, Cats has already had a thorough discussion on the subject: Issues · non/cats · GitHub).

On Dec 9, 2015, at 6:44 PM, Ilias Karim <ilias.karim@gmail.com <mailto:ilias.karim@gmail.com>> wrote:

I’m sorry, I misunderstood. I guess an enum would be the appropriate choice, instead.

As far as left/right goes, the decision to have left or right be the “correct” value is entirely arbitrary and should be left up to the developer. It should be a convention at best.

Ilias

On Dec 9, 2015, at 3:43 PM, Dave DeLong <delong@apple.com <mailto:delong@apple.com>> wrote:

With a tuple, you have to do “(left: T?, right: U?)”, whereas with an Either you are guaranteed to always have one or other other; never both and never neither. That is not guaranteed with the tuple.

Dave

On Dec 9, 2015, at 4:41 PM, Ilias Karim via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What are the advantage over using a tuple? One great feature about tuples is being able to name parameters so you can dispel ambiguity.

On Dec 9, 2015, at 3:35 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

The idea of using Left/Right is to remain agnostic to what sorts of things users might want to put in. It's feasible a user might want Either<Int, String>, not just Either<ErrorType, T>.

While I'm not sure Left & Right are the best choices, I don't think it's particularly worrisome when it comes to errors, as the general type-safety of the language will prevent users from mixing up success & error cases.

Jacob

On Wed, Dec 9, 2015 at 3:32 PM, Ilias Karim via swift-evolution<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote:
Hi Robert,

I agree with your recommendation of a generic Either type.

However, I find your use of “Right” as the “Correct” value (whatever that means) of an instance of an Either type a little perplexing. While clever, it is exactly the kind of convention that easily leads to misunderstandings about the nature of the type itself ie. is it right and left or wrong and correct? At least that is my first impression after scanning your code.

Ilias

> On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> It’s high time the STL admitted some kind of disjoint union type, at the very least because it’s such a minor addition it seems a shame to leave it out. Whatever feelings one may have about `throws`, the lack of standardizing on a datatype representing choice has caused the community to get creative and create many disjoint implementation of the same concept over and over and over again. To that end, I propose the STL ship with an Either type; We at TypeLift have already got our own we’d like to model it on (https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16\).
>
>
> ~Robert Widmann (CodaFi)
> _______________________________________________
> 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 <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 <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

33

Generics.

Also, what are the proposed injection / projection / conversion rules for structural sums? Implicit injection and dynamic cast, as if it were an existential type?

John.

···

On Dec 10, 2015, at 11:30 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

There are definitely problems if you expect them to behave like unions (so that the type `T + T` == `T`) or be unordered (so that `T + U` == `U + T`), which would be intuitively expected.

Thanks for explaining the source of complication. These definitely seem like intuitively expected behaviors.

In the context of typed throws we would expect ()->() throws MyError, YourError to be the same as ()->() throws YourError, MyError.

I have an idea that seems obvious enough that there are probably problems with it. Couldn't the type system support a canonical subset of the theoretically possible structural sum types and canonicalize structural sum types immediately when it encounters them? An obvious way to canonicalize would be to sort the types (comparator could be arbitrary as long as it was consistent) and then unique adjacent members. This seems like it would provide the intuitively expected behavior. Is this a viable approach or are there problems with it?

34

Also, are we allowed to *infer* structural sums? For example, can we decide that the type of (x ? A() : B()) is A+B if that’s the greatest common type? And do you know how to solve such typing problems efficiently in System F-sub?

John.

···

On Dec 10, 2015, at 11:49 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 10, 2015, at 11:30 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

There are definitely problems if you expect them to behave like unions (so that the type `T + T` == `T`) or be unordered (so that `T + U` == `U + T`), which would be intuitively expected.

Thanks for explaining the source of complication. These definitely seem like intuitively expected behaviors.

In the context of typed throws we would expect ()->() throws MyError, YourError to be the same as ()->() throws YourError, MyError.

I have an idea that seems obvious enough that there are probably problems with it. Couldn't the type system support a canonical subset of the theoretically possible structural sum types and canonicalize structural sum types immediately when it encounters them? An obvious way to canonicalize would be to sort the types (comparator could be arbitrary as long as it was consistent) and then unique adjacent members. This seems like it would provide the intuitively expected behavior. Is this a viable approach or are there problems with it?

Generics.

Also, what are the proposed injection / projection / conversion rules for structural sums? Implicit injection and dynamic cast, as if it were an existential type?

35

Generics.

Also, what are the proposed injection / projection / conversion rules for structural sums? Implicit injection and dynamic cast, as if it were an existential type?

Thanks for pointing out the issues that need clarification. It will give me some things to think about in the coming days.

Can you elaborate on generics a bit? Do you mean generic structural sum types, structural sum types with cases containing generic types, or both?

36

That’s what Ceylon does.

-Thorsten

···

Am 10.12.2015 um 20:59 schrieb John McCall via swift-evolution <swift-evolution@swift.org>:

Also, are we allowed to *infer* structural sums? For example, can we decide that the type of (x ? A() : B()) is A+B if that’s the greatest common type?

37

Structural sum types containing dependent types.

John.

···

On Dec 10, 2015, at 4:19 PM, Matthew Johnson <matthew@anandabits.com> wrote:

Generics.

Also, what are the proposed injection / projection / conversion rules for structural sums? Implicit injection and dynamic cast, as if it were an existential type?

Thanks for pointing out the issues that need clarification. It will give me some things to think about in the coming days.

Can you elaborate on generics a bit? Do you mean generic structural sum types, structural sum types with cases containing generic types, or both?

38

I don’t have any experience working in a language with structural sum types but I think inference of structural sums in different branches of a conditional would lead to a lot of bugs and potential confusion. Before considering support of such inference I would want to see pretty compelling evidence that it adds value and doesn’t lead to problems.

In absence of allowing this inference, the structural sum could be specified manually if that is what is intended.

···

On Dec 12, 2015, at 12:48 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

Am 10.12.2015 um 20:59 schrieb John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Also, are we allowed to *infer* structural sums? For example, can we decide that the type of (x ? A() : B()) is A+B if that’s the greatest common type?

That’s what Ceylon does.

-Thorsten

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

39

Structural sum types containing dependent types.

Dependent in what sense? Swift doesn't support anything like dependent types in the usual sense of being dependent on a value (modulo the pretty limited ability to abuse the type system).

40

I don't expect interference to lead to bugs because everything is strongly typed and you would wonder when the compile or IDE tells you that your variable or function should have type Int | String.

But requiring the result type of a conditional to be explicitly typed I could live with if I just get union types :-)

-Thorsten

···

Am 12.12.2015 um 20:11 schrieb Matthew Johnson <matthew@anandabits.com>:

I don’t have any experience working in a language with structural sum types but I think inference of structural sums in different branches of a conditional would lead to a lot of bugs and potential confusion. Before considering support of such inference I would want to see pretty compelling evidence that it adds value and doesn’t lead to problems.

In absence of allowing this inference, the structural sum could be specified manually if that is what is intended.

On Dec 12, 2015, at 12:48 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

Am 10.12.2015 um 20:59 schrieb John McCall via swift-evolution <swift-evolution@swift.org>:

Also, are we allowed to *infer* structural sums? For example, can we decide that the type of (x ? A() : B()) is A+B if that’s the greatest common type?

That’s what Ceylon does.

-Thorsten

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