On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose <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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
