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.

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-11791] Generic parameter conflict with nested iterator #54201

Open
natecook1000 opened this issue Nov 15, 2019 · 4 comments
Open

[SR-11791] Generic parameter conflict with nested iterator #54201

natecook1000 opened this issue Nov 15, 2019 · 4 comments
Assignees
@slavapestov
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@natecook1000
Copy link
Member

Previous ID SR-11791
Radar None
Original Reporter @natecook1000
Type Bug

Attachment: Download

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee @slavapestov
Priority Medium

md5: 55e235db0319c7b83e185abee50f3418

Issue Description:

I have a Tree type that is generic over Element, and defines a nested iterator that has its own element type implicitly declared as Tree<Element>. (See attached file.) This compiles without error in shipping Swift, but in swift-DEVELOPMENT-SNAPSHOT-2019-11-14-a I get this error:

IteratorElement.swift:20:12: error: type 'Tree<Element>.Iterator' does not conform to protocol 'IteratorProtocol'
    struct Iterator: IteratorProtocol {
           ^
IteratorElement.swift:48:23: note: candidate has non-matching type '<Element> () -> Tree<Element>?' [with Element = Element]
        mutating func next() -> Tree? {
                      ^
Swift.IteratorProtocol:3:19: note: protocol requires function 'next()' with type '() -> Element?'
    mutating func next() -> Self.Element?
                  ^

I can fix the problem by changing the name of Tree's generic parameter to TreeElement.
@slavapestov
Copy link
Member

I reverted the change in question, however I can bring it back without breaking your code, because note that 'Element' is not a generic parameter of Iterator itself, but of its outer type. It should not be a candidate for inference.

@natecook1000
Copy link
Member Author

So in your pitch (https://forums.swift.org/t/infer-associated-types-as-generic-parameters-more-eagerly/30833), only the generic parameters on the specific type conforming to a protocol P should be candidates for P's associated types? That makes sense.

@slavapestov
Copy link
Member

Yes, that is correct. I believe it was an oversight that we always look at the "innermost" generic parameters even if the type is not generic.

@slavapestov
Copy link
Member

Actually your code also relies on Sequence.Element := Tree<Element> in the outermost type too, because the witness comes from the iterator's element type. So this would be another source break from my proposal unfortunately. Maybe the proposal isn't worth it?

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slavapestov slavapestov

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@slavapestov @natecook1000