[swift-evolution] [proposal] Either in the Swift Standard Library

[Developer]

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

Because this is a non-goal of the type.  A sum in languages without variadic generics is finite and generalizes to higher cases by nesting in the lobes.  I'm sorry if the proposal have the impression sums were supposed to complement products, because that's not what we wanted for the standard library or the language when even tuples don't have a first-class representation yet.

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

You know my counterarguments about the name.  But at this point as long as I get an unconstrained Result in two type parameters I'm fine because that's the structure we are advocating for in the proposal.  

Everything else is orthogonal to the original design and frankly is kind of frustrating to argue about because I never understand which "Either" people have in their heads - but it seems it's rarely the one in the actual proposal.  I should have used the term "sum" from day one, I realize that now.

~Robert Widmann

2016/01/26 18:56、Chris Lattner <clattner at apple.com> のメッセージ:

>> On Jan 26, 2016, at 2:24 PM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
>> Okay, we’ll stop quibbling about the name (I’ll try to use “sum” from here on out), I want to focus on the first part of this because I think it’s great.  There are definitely limitations to extensions like that, but I don’t think they should impede the inclusion of the data type itself.  For one, if we’re going to focus on strong typing, then it not being usable seems a feature not a bug.  Can you think of any more in with respect to the fully-generic form?
> 
> I am also becoming more strongly opposed to this proposal the more discussion goes on.  Here’s another direction to try to convey this:
> 
> 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.
> 
> 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?
> 
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/5b31f221/attachment.html>