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

[John McCall]

> On Dec 10, 2015, at 11:49 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> On Dec 10, 2015, at 11:30 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>> There are definitely problems if you expect them to behave like unions (so that the type `T + T` == `T`) or be unordered (so that `T + U` == `U + T`), which would be intuitively expected.
>> 
>> Thanks for explaining the source of complication.  These definitely seem like intuitively expected behaviors.  
>> 
>> In the context of typed throws we would expect ()->() throws MyError, YourError to be the same as ()->() throws YourError, MyError.
>> 
>> I have an idea that seems obvious enough that there are probably problems with it.  Couldn't the type system support a canonical subset of the theoretically possible structural sum types and canonicalize structural sum types immediately when it encounters them?  An obvious way to canonicalize would be to sort the types (comparator could be arbitrary as long as it was consistent) and then unique adjacent members.  This seems like it would provide the intuitively expected behavior.  Is this a viable approach or are there problems with it?
> 
> Generics.
> 
> Also, what are the proposed injection / projection / conversion rules for structural sums?  Implicit injection and dynamic cast, as if it were an existential type?

Also, are we allowed to *infer* structural sums?  For example, can we decide that the type of (x ? A() : B()) is A+B if that’s the greatest common type?  And do you know how to solve such typing problems efficiently in System F-sub?

John.