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

[Craig Cruden]

Same could be said of a n-tuple - it is pretty niche version of an array with n elements :p

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.   

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.

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.

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).

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.  




> 
> 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.
> 
> 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:
> 
> 	func myFunc() -> Int, Double, String { … }
> 
> This could then create an implicit enum that I could then check via cases like:
> 
> 	case .Double(value): doSomething(value)
> 	case .Int(value): doSomethingElse(value)
> 	case .String(value): doSomethingStringy(value)
> 
> 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.
> 
> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/4673320e/attachment.html>