[SR-4758] SE-0142: derived protocol that restricts associatedtype should be allowed as a variable type

[nsalmoria]

Previous ID	SR-4758
Radar	rdar://problem/58438127
Original Reporter	@nsalmoria
Type	Improvement

Environment

Swift Development Snapshot 2017-04-24 (a)
Xcode 8.3.2
macOS Sierra 10.12.4

Additional Detail from JIRA

Votes	3
Component/s	Compiler
Labels	Improvement
Assignee	@slavapestov
Priority	Medium

md5: 992bea1bd30120d41ee308b8b85d8e1e

is duplicated by:

• [SR-7336] Protocol with same-type constraint on associated type "can only be used as generic constraint" #49884
• [SR-9260] Allow protocol types with fully specified associated types in all type positions (function arguments etc.) #51737
• [SR-9501] Subclass existential with predefined associated type witness should be supported as existential #51955

relates to:

• [SR-13502] Have to place empty generics when using protocol + where cause in function #55944

Issue Description:

With the implementation of SE-0142, it is now possible to force the associated types of a derived protocol to be of a specific type.

Arguably, when all the associated types are restricted, it should be possible to use the derived protocol as the type of a variable. However, the compiler still rejects the code.

Example:

protocol A {
    associatedtype B
}

protocol C: A where B == Int {

}

struct D {
    var c: C  // error: Protocol 'C' can only be used as a generic constraint because it has Self or associated type requirements
}

In the example above, protocol C has no degrees of freedom so it shouldn't need to be restricted to generic code.

[swift-ci]

Comment by Simon Coulter (JIRA)

I'm not sure if this is same issue or not but same thing happens with a derived protocol that specifies the associated type. it should no longer have same requirements.

protocol GenericProtocol {
    associatedtype Element
    func doSomething(element: Element)
}

protocol SpecificProtocol: GenericProtocol {
    func doSomething(element: Int)
}

protocol CanDoSomething {
    // Error: Can only be used as a generic constraint requirement because it has self or associated type requirements
    func canDoSomethingWith(specific: SpecificProtocol)
}

[AnthonyLatsis]

@slavapestov, have you started working on this? If not, would you agree to mentor me over the issue? I've already experimented for some time, but got stuck on trying to make the CS catch a same-type constraint when there is no archetype.

[beccadax]

@swift-ci create

[swift-ci]

Comment by Thibault Martin-Lagardette (JIRA)

Hello!

I can see this ticket had a pull request, but that it ended up being closed without being merged.

Is there any work planned on this? If not, any way anyone could help?

I have yet to contribute to Swift, so it would take me a while to get something out, but with some help/pointers and previous attempts, I feel I could at least give it a try!

Would it first need a proposal, as mentioned by Joe Groff in the forums?

[AnthonyLatsis]

Hi! This will be proposed alongside swiftlang/swift-evolution#1176. We're hoping to schedule the review in a matter of days or weeks. The implementation's at #33767, but there is some accumulated downstream work too. Feel free to throw in any suggestions!

P.S. Have you considered having a go at some starter bugs?

[slavapestov]

This is implemented in Swift 5.7 as part of SE-0309.

[lutes1]

As of Swift 5.10, this issue is still not resolved, SE-0309 only masks the issue but does not resolve it. We still have to use any which comes with its own limitations.

Considering the example described initially in this issue, the protocol C should behave as any other protocol without Self or associatedType requirements, which is not currently the case.

Updated example:

protocol A {
    associatedtype B
    var item: B { get }
}

protocol C: A where B == Int { 

}

struct D {
    var c: C  // error: Use of protocol 'C' as a type must be written 'any C'
}

The expected behaviour is that the 'C' protocol should not behave any different than

protocol E {
    var item: Int { get }
}

(Please let me know if I'm missing something)

[AnthonyLatsis]

Requiring any syntax here is intentional. any was initially enforced under the exact same legacy criteria that protocols with "Self or associated type" requirements were once prohibited in existential types pre SE-0309. where B == Int never counted to whether a protocol has "Self or associated type" requirements. We are moving toward obsoleting this old and misleading term and the code supporting it with a world where any is always required on existentials, or, just maybe, something different. Changes to the definition of a "Self or associated type" requirement would take us a step back and aggravate a likely future migration at this point.