Implement a warning, if a subclass doesn't conform to the protocol of the parent class

Using @_implements with something that isn't part of the protocol triggers an error, doesn't it?
So afaics all that is missing is syntactic sugar that maps Protocol.requirement (or Protocol::requirement, or ...) to @_implements(Protocol, requirement).

As far as I know that attribute exists (and has probably been locked down with the ABI) as a hack to treat a certain typealias as a default for Indices in a constrained protocol extension.

It's not quite that simple. @_implements affects name resolution in subtle ways and is not sufficiently general to be 'made public' as is. A version of the attribute, could eventually be introduced with semantics similar to what you describe, but it would take a substantial design and implementation effort

This is not an extension, it's a new protocol that is based on another protocol. You also make a difference between subclassing and extending a class, don't you? :slight_smile:

As I said, I think that the actual way how Swift uses the extension-keyword is wrong, because it doesn't extend the protocol. I really would like to make a pitch, but to be honest, I'm totally new to this (would this also mean to make a pull request to the compiler?). I will try to open one.

No. Extending a class in other languages is only allowed via subclassing. Extending a class in Objective-C can be done via a similar mechanism as Swift, but you can't add anything that would change the layout of the class, so you can only add methods. Same in Swift, you can only "extend" a class in Swift by adding methods or computed variables (which are really just getter/setter methods). Extending a protocol means the same, you're adding new method implementations that conforming objects can utilize if they know about them.

As I said previously, extending a protocol by adding new requirements or constraints only works if you have the code to all the existing objects that conform to the "old" protocol so they can be modified to conform to the new requirements. If have that, then why bother "extending" the protocol, just modify the old one and re-compile. If you don't, like with binary frameworks or libraries, trying to extend the protocol as you suggest means I have to have a concept of "partially conforming" since objects that conform to the unextended protocol definition cannot be made to conform to the extended protocol, which is now the protocol definition.

You extend protocols for your code by "sub-classing" if you will existing protocols, like I indicated previously.

You can make a pitch, however, at some point, someone is going to have re-write a good portion of the compiler to implement the concept of "partial conformance."