[swift-evolution] Proposal: Sealed protocols

[Adrian Kashivskyy]

> 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’.

I think it's wiser to refactor those protocols to be public and fully usable than to insert another access modifier to a language. Contracts that say "public but please don’t use" are generally a sign of design that is poor or limited by language/compiler.

Pozdrawiam – Regards,
Adrian Kashivskyy

> Wiadomość napisana przez Felix Gabel <felix.gabel at me.com> w dniu 04.12.2015, o godz. 01:45:
> 
>> 
>> On Dec 4, 2015, at 12:25 AM, Dmitri Gribenko <gribozavr at gmail.com <mailto: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
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/791855cc/attachment-0001.html>