<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><blockquote type="cite"><div class=""><div class=""><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">This means that it will not be unconstrained, and not a generic type like the Either you are proposing.</span></font></div></div></blockquote></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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, </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">extension Result where E : ErrorType </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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. <br><br>~Robert Widmann</div><div><br>2016/01/27 1:31、Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 26, 2016, at 7:50 PM, Developer <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">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.<br class=""></span></font></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote></div><br class=""><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">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. <br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">This means that it will not be unconstrained, and not a generic type like the Either you are proposing.</div><div class=""><br class=""></div><div class="">-Chris</div></div><div class=""><br class=""></div></div></blockquote></body></html>