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

[SR-6981] @_implements doesn't work in extensions #49529

Open
xwu opened this issue Feb 11, 2018 · 6 comments
Open

[SR-6981] @_implements doesn't work in extensions #49529

xwu opened this issue Feb 11, 2018 · 6 comments

Comments

@xwu
Copy link
Collaborator

@xwu xwu commented Feb 11, 2018

Previous ID SR-6981
Radar None
Original Reporter @xwu
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: c2eb03bd88ab046fae58ebe4fa85ad8f

Issue Description:

PR #8735 adds supports for @_implements, which serves some niche but important purposes in the standard library.

Currently, we’re running into some potential source breakage with conditional conformances (for standard library types) for which @_implements would be perfect. However, it seems like this attribute simply doesn’t work inside extensions. By which I mean, the following compiles:

protocol P {
  func f(x:Int, y:Int) -> Int;
}

struct S : P {
  @_implements(P, f(x:y:))
  func g(x:Int, y:Int) -> Int {
    return 5
  }
}

…but adding the following doesn’t:

protocol Q {
  func f(x:Int, y:Int) -> Int;
}

extension S : Q { // Error: Type 'S' does not conform to protocol 'Q'
  @_implements(Q, f(x:y:))
  func h(x:Int, y:Int) -> Int {
    return 6
  }
}

This makes @_implements unusable for conditional conformances 🙁

@belkadan
Copy link
Contributor

@belkadan belkadan commented Feb 12, 2018

Given that @_implements can result in weird diagnostics I don't think it was really intended to be used anywhere but for compiler-synthesized == yet. But if it really would be useful I don't think there's an inherent reason not to allow it in extensions. graydon (JIRA User), thoughts?

@xwu
Copy link
Collaborator Author

@xwu xwu commented Feb 12, 2018

The intended use here is for conditional implementations of == in the standard library, so we wouldn’t be stretching very far. I can see that the diagnostics are hardcoded but this isn’t going to be a problem for the intended use as it requires very little additional code to have the diagnostics cooperate here.

The workaround I could devise today requires a public underscored protocol, so being able to eliminate that from the ABI would be nice (TM).

@belkadan
Copy link
Contributor

@belkadan belkadan commented Feb 13, 2018

Sorry, the diagnostics I'm talking about are when the member that uses _implements ends up getting mentioned for some reason, not the diagnostics around _implements itself. People don't expect it to have a different name. (This doesn't happen very often, but...)

@xwu
Copy link
Collaborator Author

@xwu xwu commented Feb 13, 2018

That's what I'm talking about as well 🙂

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Feb 13, 2018

Comment by Graydon Hoare (JIRA)

Seems plausible to me; probably just an oversight in the implementation.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Dec 3, 2020

Comment by Zsolt Kovacs (JIRA)

@xwu it seems like this issue got fixed at one point as this compiles now:

protocol Q {
  func f(x:Int, y:Int) -> Int
}


struct S {}


extension S : Q { // Error: Type 'S' does not conform to protocol 'Q'
  @_implements(Q, f(x:y:))
  func h(x:Int, y:Int) -> Int {
    return 6
  }
}

@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
Projects
None yet
Development

No branches or pull requests

3 participants