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.
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 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@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