[swift-evolution] Proposal: An Either Type in the STL
thorsten.seitz at web.de
Thu Dec 10 13:05:14 CST 2015
> 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).
>> 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.
> 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...
More information about the swift-evolution