@swift-ci create

Comment by Owen Voorhees (JIRA)

This sounds sort of like https://bugs.swift.org/browse/SR-5260 to me in that if this was allowed, flipping the order would have a slightly different meaning w/ regard to access control. Doesn't seem like a reason to disallow it though.

owenvoorhees (JIRA User) In my opinion, SR-5260 is more of a distinct feature ("allow protocol compositions in extended types") than this one. We already allow classes in extended types today, only without 'where' clauses.

Also, the concern raised there was about Swift 4. I'm not sure if Swift 5 shares the same access control model.

It does. The only changes to access control between Swift 4 and Swift 5 were patching holes (things that should not have been allowed in Swift 4's model that went undiagnosed).

cc @slavapestov @DougGregor for opinions.

(I'm of the opinion that this should be allowed for non-final classes but I also see why it's annoying to implement.)

Intuitively I can see why this should be allowed to work, however "Self" is not a type parameter that can be constrained in class extensions. I think it would be a fairly big change to make this work. For one, it would change the mangling in all class extensions, since the type of "self" would now be a type parameter and not a class.

We could limit that to extensions of classes that actually constrain Self, at least, but yeah.