Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
nsalmoria opened this issue May 1, 2017 · 6 comments
Closed

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

nsalmoria opened this issue May 1, 2017 · 6 comments
Assignees
@slavapestov
Labels
compiler The Swift compiler in itself existentials Feature: values of types like `any Collection`, `Any` and `AnyObject`; type-erased values feature A feature request or implementation improvement swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented type checker Area → compiler: Semantic analysis

Comments

@nsalmoria
Copy link
Contributor

nsalmoria commented May 1, 2017 •
edited by AnthonyLatsis

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"
  • SR-9260 Allow protocol types with fully specified associated types in all type positions (function arguments etc.)
  • SR-9501 Subclass existential with predefined associated type witness should be supported as existential

relates to:

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

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
Copy link
Collaborator

swift-ci commented Jun 27, 2017 •
edited by AnthonyLatsis

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
Copy link
Collaborator

@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
Copy link
Contributor

@swift-ci create

@swift-ci
Copy link
Collaborator

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
Copy link
Collaborator

Hi! This will be proposed alongside apple/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?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@slavapestov
Copy link
Member

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

@AnthonyLatsis AnthonyLatsis added feature A feature request or implementation type checker Area → compiler: Semantic analysis swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented existentials Feature: values of types like `any Collection`, `Any` and `AnyObject`; type-erased values labels Jan 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slavapestov slavapestov

Labels
compiler The Swift compiler in itself existentials Feature: values of types like `any Collection`, `Any` and `AnyObject`; type-erased values feature A feature request or implementation improvement swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@slavapestov @beccadax @swift-ci @AnthonyLatsis @nsalmoria