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 <spes...@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@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@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
