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

[Chris Lattner]

> 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/20160126/447a3229/attachment.html>