<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">How do you expect people will use the result of such an operation in practice? The type being 'Any' makes it completely opaque.</div></div></div></div></blockquote><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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.</div></div></div></div></blockquote><div class=""><br class=""></div>Perhaps it would be better to recursively unify parameters/returns into their own unions, such that<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">final class Socket {</div><div class=""> func getsockname() -> union(Any, [sockaddr_in, sockaddr_in6])</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Did you look at AnySequence and other related types that implement a similar pattern manually?</blockquote></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>