Making a protocol's associated type concrete via inheritance

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

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

1 Like

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

Bumping this.

Is it still the case that the restriction on using protocols as types is artificial?

This issue seems to still manifest in the latest Swift 5 builds.

The restriction still exists. There's a pitch thread about removing this restriction in general:

We also have a patch from @anthonylatsis that lifts this restriction specifically on protocols that bind away all of the associated types:

To make this change official, we would still need a proposal to review.

1 Like

Thanks for the reply and for the pointers!

Terms of Service

Privacy Policy

Cookie Policy