[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu]

On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose <jordan_rose at apple.com> wrote:

> P.S. There’s also an argument to be made for public-but-not-conformable
>> protocols, i.e. protocols that can be used in generics and as values
>> outside of a module, but cannot be conformed to. This is important for many
>> of the same reasons as it is for classes, and we’ve gotten a few requests
>> for it. (While you can get a similar effect using an enum, that’s a little
>> less natural for code reuse via protocol extensions.)
>>
>
> Would public-but-not-conformable protocols by default be the next step,
> then, in Swift's evolution?
>
>
> I personally think it’s a reasonable place to go next, which is why I
> brought it up. However, I don’t think it’s critical enough to get into
> Swift 3 when we’re already so busy, and when there are multiple
> non-source-breaking ways to get a similar effect later: adding a “sealed”
> annotation (so, giving up on “by default” for protocols) and allowing
> requirements to have more narrow access than the protocol (thus making it
> impossible to conform).
>

FWIW, if we give up on "by default" for classes, "sealed" could also be a
post-Swift 3 matter here as well. IMO, if the core team finds the reasoning
here persuasive enough to have sealed-by-default for classes, I'd hope for
the same treatment for protocols on that time frame, because as you say
much of the rationale behind the change is analogous for both protocols and
classes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/c2465423/attachment.html>