[swift-evolution] union types

[Drew Crawford]

> How do you expect people will use the result of such an operation in practice?  The type being 'Any' makes it completely opaque.

> If your library is a high-level one, I definitely wouldn't want to see it return 'Any' from Socket methods.  Instead, a library should erase the differences between transport mechanisms in the high-level API, while still providing a low-level API for those who need it, as well as for the implementation of the high-level API.

Perhaps it would be better to recursively unify parameters/returns into their own unions, such that

final class Socket {
    func getsockname() -> union(Any, [sockaddr_in, sockaddr_in6])
}

> Did you look at AnySequence and other related types that implement a similar pattern manually?


AnySequence has a different motivation.  In AnySequence, the underlying type is fully erased, or alternately, the underlying type is an element from an open set.  This is appropriate for a public API where the user may create their own types unknown to the library author which need to be erased.

In a union, the underlying type is only partially erased, or alternately, the underlying type is an element from a closed enumeration.  This is appropriate for a private/internal API where the types are known at compile time.

I suspect it would be difficult to automatically unify an *open* set of types, which is why AnySequence et al are manually maintained.  But unifying a *closed* set of types can be implemented in a preprocessor.  So unification is much more appropriate in this case.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/82d9d812/attachment.html>