[swift-evolution] Proposal: Sealed protocols

[Felix Gabel]

> On Dec 4, 2015, at 12:25 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> On Thu, Dec 3, 2015 at 3:09 PM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
> >
> >> On Dec 3, 2015, at 2:59 PM, Felix Gabel <felix.gabel at me.com <mailto:felix.gabel at me.com>> wrote:
> >>
> >> Hey everyone,
> >>
> >> I hereby propose adding a ’sealed’ modifier for protocols to enable library developers to declare protocols that can be only conformed to in the scope of the library itself. This is similar to a ’sealed trait’ in Scala with the difference that it does not limit the protocol to be only applicable in the file it is declared in.
> >>
> >> Example:
> >>
> >> public sealed protocol FooType {
> >>    // this protocol can be conformed to only in scope of the library itself
> >>    // it can NOT be conformed to by any object declared outside the library
> >> }
> >>
> >> What do you think?
> >
> >
> > Can you elaborate on why a Swift developer would want to distinguish between “public sealed” and “internal”?
> 
> There are cases when the library isn't designed to support new conformances for the protocol, but the protocol is public because other public APIs are expressed in terms of it.
> 
> We have a case for it in the standard library, 'protocol AnyCollectionType'.  Foundation also has a use case -- property list types.
> 
> Dmitri

- protocols starting with an underscore (_ArrayBufferType, _IntegerType, etc) would benefit from the ’sealed’ modifier, because the contract right now only implicitly says: ‘public but please don’t use’.
- another use case is grouping a set of types regardless their origin and limit the ability to extend the provided number of types by external forces


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/eff0486f/attachment.html>