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

[Matthew Johnson]

> On Jul 11, 2016, at 1:49 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose <jordan_rose at apple.com <mailto: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.

On the topic of protocols, there are really two avenues for “sealing”’ them.  One is conformances and the other is refinements.  There are more nuances to consider in a design for sealing protocols.

If we’re going to continue discussing sealing protocols we should probably start a new thread.  However, I think we should wait unless someone from the core team decides it is worth discussing during the Swift 3 timeframe.

> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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