[swift-dev] Making a protocol's associated type concrete via inheritance
swift at lng.la
swift at lng.la
Sun Aug 27 20:37:50 CDT 2017
Thanks for the info Slava! Is that change something that would need to go through swift evolution? I would think so, but I'd like to confirm since I may be interested in looking into it.
Jarod
On Aug 27, 2017, 16:35 -0700, Slava Pestov <spestov at apple.com>, wrote:
> This is not supported right now but it is within the realm of possibility of things that we can support.
>
> The restriction on using protocols as types is artificial — it was put in place to avoid confusing users. So it is a matter of tweaking the logic which diagnosed unsupported protocol types to somehow check for fully-constrained associated types instead.
>
> Slava
>
> > On Aug 27, 2017, at 2:54 PM, Jarod Long via swift-dev <swift-dev at swift.org> wrote:
> >
> > Apologies for any terminology that I'm not using correctly, but I'm wondering if there's any way to make this work in Swift 4:
> >
> > ```
> > protocol P1 {
> > associatedtype Thing
> > func makeThing() -> Thing
> > }
> >
> > protocol P2: P1 where Thing == String {}
> >
> > func test(_ p2: P2) { // Can only use P2 as a generic constraint even though P2.Thing should be known to be String
> > print(p2.makeThing())
> > }
> > ```
> >
> > I want P2 to conform to P1 and make its associated type concrete so that it can be used directly. If this isn't possible right now, are there any plans for something like this to be added in the future? I've looked through the generics manifesto, but I didn't see anything that seemed to address this issue.
> >
> > Thanks!
> >
> > Jarod
> > _______________________________________________
> > swift-dev mailing list
> > swift-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170827/7bbcfa7c/attachment.html>
More information about the swift-dev
mailing list