# Sealed protocols

**URL:** <https://forums.swift.org/t/sealed-protocols/19118>\
**Category:** Pitches\
**Created:** [December 28, 2018, 6:57am UTC](https://forums.swift.org/t/sealed-protocols/19118 "2018-12-28T06:57:54Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [December 28, 2018, 7:19am UTC](https://forums.swift.org/t/sealed-protocols/19118/2 "2018-12-28T07:19:00Z")

</div>

> [@Karl](#):
>
> Refinements of sealed protocols must also be sealed, which means they too are only possible within the parent's declaring module.

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.

```swift
// 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:

> [@\[Draft\] open and public protocols](https://forums.swift.org/t/draft-open-and-public-protocols/5244):
>
> Now that we’re in phase 2 I’d like to officially propose we introduce `open` protocols and require conformances to `public` protocols be inside the declaring module. Let’s use this thread for feedback on the official proposal. After a healthy round of discussion I’ll open a PR to submit it for review. # Feature name \* Proposal: [SE-NNNN](NNNN-open-public-protocols.md) \* Authors: [Matthew Johnson]([https://github.com/anandabits\](https://github.com/anandabits%5C)) \* Review Manager: TBD \* Status: \*\*Awaiting review\*\* ## Intr…

> [@\[Pitch\] consistent public access modifiers](https://forums.swift.org/t/pitch-consistent-public-access-modifiers/5129):
>
> I’ve been thinking a lot about our public access modifier story lately in the context of both protocols and enums. I believe we should move further in the direction we took when introducing the `open` keyword. I have identified what I think is a promising direction and am interested in feedback from the community. If community feedback is positive I will flesh this out into a more complete proposal draft. Background and Motivation: In Swift 3 we had an extended debate regarding whether or n…

> [@\[Late Pitch\] open/public protocols](https://forums.swift.org/t/late-pitch-open-public-protocols/3834):
>
> Hello dear Swift community, I was updating some of my libraries where I noticed that the new open access modifier made the public modifier inconsistent in one way. Conformances to protocols is logically the same as inheritances on classes. Conformances == (abstract) inheritance That said we should allow protocols to be open/public like we now allow this distinction for classes. open protocol from module A should mean that I’m allowed to conform to it in module B public protocol will act as…

> [@Constrain protocol usage outside the module](https://forums.swift.org/t/constrain-protocol-usage-outside-the-module/8832):
>
> Hello Swift community, I know I know, some of our souls are bleeding after the tiring mail-list discussions in dozens of similar threads, but I still feel that we have finally to sort this out. In the end we also moved to a forum not only for discoverability of older topics and better communication, but also to be able to push the language forward without necessarily relying on the help of the core team. In fact this is also implied by the new review rules where we must provide an implementatio…

---

_[View the full topic](https://forums.swift.org/t/sealed-protocols/19118)._