[swift-evolution] union types
Dmitri Gribenko
gribozavr at gmail.com
Fri Dec 11 17:39:03 CST 2015
On Fri, Dec 11, 2015 at 3:22 PM, Drew Crawford via swift-evolution <
swift-evolution at swift.org> wrote:
>
> func make() -> Any {
>
>
What about parameter types that you erase, would you downcast and trap in
case of mismatch?
Did you look at AnySequence and other related types that implement a
similar pattern manually?
How do you expect people will use the result of such an operation in
practice? The type being 'Any' makes it completely opaque.
Motivating case:
>
> This proposal arises (most recently) from the problem of trying to write
> code that is generic across IPv4 and IPv6. For example
>
> final class Socket {
> func getsockname() -> ???
> }
>
>
> In the IPv4 case this function should return `sockaddr_in`, but in the v6
> case it should return `sockaddr_in6`. So this socket can only be
> represented as a protocol with associated type requirements, and so it
> cannot be trivially used e.g. as a function parameter, as an ivar, etc.
> This significantly complicates the implementation.
>
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.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/86a6da1d/attachment.html>
More information about the swift-evolution
mailing list