I think this restriction is irrelevant to the proposed core feature because of retroactive conformances. I think we should allow refinement of sealed protocols outside the parent module, and restrict the conformance to the new protocols only to the module where the parent sealed protocol comes from.
// Module B
// this should be okay
protocol SpecialProtocol: ASealedProtocol {}
// Error: cannot conform to protocol 'SpecialProtocol' refining a sealed protocol 'ASealedProtocol' outside of its declaring module.
struct MyTypeFromB: SpecialProtocol {}
// Retroactive conformance should be okay
extension MyType: SpecialProtocol {}
That particular case was discussed in previous threads, I'll link those if I find them.
I always wanted this feature and I wanted it the right way from the start. In my eyes it should be as simple as open / public protocol, but this is such a pity story in Swift's history during the late pre Swift 3 timeframe where open class was introduced. Even during the review of that feature people raised concerns of the misalignment it would generate for protocols because public on protocols would mean that you can conform to the protocol outside the parent module while on classes the analog behavior of subclassing was 'sealed' under the public access modifier and can only be opened by using the open access modifier. Now the defaults are flipped for protocols and open is an exclusive access modifier for classes which in my opinion is loosey goosey.
Every time I brought up this topic, everyone shouted at me that the ship is sailed to introduce the convenient way of expressing this functionality as open / public protocol, so I guess we cannot find a way to achieve it in a source compatible and non mind bending way such as introducing open protocol and migrating every public protocol to it, then forbid somehow public protocol usage until it can be re-invented in the sealed way.
If that still holds true, and the current behavior is flipped I think the only convenient route we can go now would be by introducing another exclusive access modifier just for protocols.
| classes | protocols |
|---|---|
open class |
public protocol |
public class |
sealed protocol |
That way sealed would be another access modifier, which like open would used for publishing API outside the parent module. Only this time it will restrict something rather than permit something (compared to open).
Here are a few related topics I could find for the readers of this thread: