[swift-evolution] Proposal: An Either Type in the STL

[Thorsten Seitz]

> The point of typed “throws” is to allow E to be more constrained.  In the simplest case, E might be one specific type; it might then make sense to be able to write Result<T, E>.  However, there are more complex cases.  For example, it might be possible to say (Java-like) that a function can throw any one of a set of different error types; would this have to be expressed as Result<T, E1, E2, E2, …>?  That’s a tough fit for the generics system, especially since the error types are logically a set, not a sequence.  

You could just write Result<T, E1 | E2 | E3> where "|" is the type union operator if we had union types as in Ceylon (see http://ceylon-lang.org/documentation/tour/types/).
I’ve mentioned them once or twice on this list already and I do think they are really really powerful and useful while staying totally intuitive!

> Now, you could try to disallow this by saying that functions have to pick a single type that they can throw (e.g. ErrorType); but this doesn’t actually solve the problem, because expressions can contain multiple throw sites with different error types, so now you’ve got a set again.  Again, you can force that back to the greatest common type (which will generally be ErrorType), but now Result loses information that normal type-checking would have preserved.  So it’s a challenge.

With union types no information is lost. I was really surprised how well they worked out in Ceylon (and I think the Ceylon guys were themselves pleasantly surprised, too).

-Thorsten

> 
>> When it comes back up and assuming we have typed throws I would like to see support for multiple error types.  I think it could be accomplished via an anonymous compiler generated sum type or something similar to that.  
> 
> Structural sum types (as opposed to nominal sum types like Either which are explicitly formed and broken down) are a massive complication for type systems.
> 
> John.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/960c2977/attachment.html>