> On Jul 11, 2016, at 1:49 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose <jordan_r...@apple.com > <mailto:jordan_r...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
