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

[Developer]

> This means that it will not be unconstrained, and not a generic type like the Either you are proposing.


I feel I've elaborated on all of this in the huge email.  I believe we want the same things, I just need to keep the shape of the type in the proposal intact no matter what it's called.  It's always easier to get more domain-specific as time goes on and these things are actually worked out.  But to start with a narrow domain and go wider is far more difficult.  I think the constraint would limit future uses of the type in non-error-handling situations because, as we note in the proposal, though that is the common case it is not the only one.  Besides, 

extension Result where E : ErrorType 

accomplishes the goal of including domain-specific methods on the type but keeping it generic and usable for those remaining 10% of cases you don't need them. 

~Robert Widmann

2016/01/27 1:31、Chris Lattner <clattner at apple.com> のメッセージ:

> 
>>> On Jan 26, 2016, at 7:50 PM, Developer <devteam.codafi at gmail.com> wrote:
>>> 
>>> 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.
> 
> Robert, I really really do understand (and respect!) the type theory behind sum types, it is something I’m quite familiar with.  I also agree that (without variadic generics) we cannot do a reasonable n-ary version of Either. 
> 
> The problem is that you’re making a type theory argument, not a practical argument.  Your argument comes across to me as “this is the best we can do”, but I’m looking for what practical problems that are solved by adding this type to the standard library.  As has been discussed already, a Result type has many interesting applications and serves many known use cases.
> 
> To convince me (since I’m speaking for myself, not for other folks on the thread) you’d need to convince me that there is a niche served by the Either type that is worth the cost of adding to the standard library.
> 
>> 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.  
> 
> To set expectations, I’d expect the Result type to be specifically designed to serve the problem domain of capturing a return value.  Even assuming we get “typed throws”, I’d expect the error argument to have an ErrorType constraint on it.  Further, if we expand the function result type model, we’d expect Result to track that.  I would also expect the Result type to have methods on it specific to its domain.
> 
> This means that it will not be unconstrained, and not a generic type like the Either you are proposing.
> 
> -Chris
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160127/d973de8d/attachment-0001.html>