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?

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).

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...)

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

Comment by Graydon Hoare (JIRA)

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

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
  }
}