<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></body></html>