<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=""><div class="">Same could be said of a n-tuple - it is pretty niche version of an array with n elements :p</div><div class=""><br class=""></div><div class="">I would argue that returning either of two types is a very common occurrence (more-so with functional style of programming). If each functionally oriented library were to independently implement Either (which is what is happening now) — becomes a less than ideal situation. I find it actually funny that there is talk about beefing up generics for generic programming, but generic types apparently are problematic :p. </div><div class=""><br class=""></div><div class="">As for the the straw man argument if two then what about three — is that a common scenario? I have never had a situation like that in any paradigm that was not a symptom of the coder doing something seriously wrong.</div><div class=""><br class=""></div><div class="">For procedural programmers you have the option of mutating (inout) parameter on a function (something I find really really ugly as a solution). Throwing “try” exceptions for handling errors is common in things like Java and Swift (and as procedural error handling), but quickly become a nightmare of scrambled code.</div><div class=""><br class=""></div><div class="">I am looking right now at a Java class that has a couple hundred validations just on “Account” — some hard (i.e. error) some configurable (turn on or turn off for a logged on user), some overridable. Because someone was afraid of a generalized solution and wanted a specific one situations like this may be unforeseen and not fit in a specialized (aka niche) solution. Creating specialized implementations like `Result` requires a form of ESP to correction foresee every possible case, while Either is just really Either of two types (a common occurrence).</div><div class=""><br class=""></div><div class="">Throwing Exceptions (especially when you are returning a list of different property validations of everything that is wrong - so you don’t leave the user going back and fixing one property at a time then trying again) is not great. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">Personally I agree that this is pretty niche these days; if I want to return either a result or an error, then I now have the option of throwing an exception, and this in my experience was the most common case where something like this was needed.</div><div class=""><br class=""></div><div class="">If the aim is to allow a function to return one of several possible types, then the question is… why only two? If we were looking at allowing several possible return types then what I’d really rather see is some kind of compiler magic that supports that, so I could do stuff like:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func myFunc() -> Int, Double, String { … }</font></div><div class=""><br class=""></div><div class="">This could then create an implicit enum that I could then check via cases like:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .Double(value): doSomething(value)</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .Int(value): doSomethingElse(value)</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case .String(value): doSomethingStringy(value)</font></div><div class=""><br class=""></div><div class="">There could also be some kind of naming syntax, to enable returning one of two possible values of the same type, but with different meanings, otherwise the case would be implicitly named for the type of data that it holds.</div><div class=""><br class=""></div><div class="">Otherwise… I think use of Either is too specialised, and too easily done yourself with a name that’s more specific to your use-case.</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>