cc @slavapestov, @DougGregor

It's not actually an associated type at all (maybe it was at some point?) I'll remove the comment and add a different one in ProtocolDecl.

#21018

Comment by mohammad faani (JIRA)

Thank you for your swift action
@slavapestov

Me and a senior a dev are a bit confused by your new comment. Protocols can't have generic parameters.
Do you mean something like this is happening under the hood:

protocol P<Self> {
// not sure what property name I should put here maybe _self
 var _self : Self
}

error: protocols do not allow generic parameters; use associated types instead
Can you explain it a bit more?

I'm also wondering if there is any significance in your example:

protocol Cloneable {
   func clone() -> Self
}

Could you have just wrote the following as your example too?

protocol S {}

Yes, the 'Self' generic parameter is created under the hood. Protocols cannot have user-defined generic parameters. The Cloneable example is there just to show a usage of 'Self'.

Comment by mohammad faani (JIRA)

hmmm.
we mere mortals and you Asgardians!

So does this also have the 'implicitly-created 'Self' generic parameter'?

protocol S {}

I guess it doesn't right?

Or that it does, but since there isn't any usage of `Self` then no requirement is created at the protocol level.

All protocols have a 'Self' parameter. The check for being able to use a protocol as a type looks as the signature of each method requirement to see if Self appears in a parameter position (note that Self in a return position, as in the Cloneable example, does not prevent you from using the protocol as a type).

@slavapestov Was happy see half the WWDC 2022 - Design protocol interfaces in Swift talk is about this :D

"We mere mortals and you Asgardians!" above, still applies. Your bug pin is 10X cooler than the ones we got at the conference :)