> 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).
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
