<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 11, 2016, at 1:49 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose <span dir="ltr" class=""><<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.)</div></div></blockquote><div class=""><br class=""></div><div class="">Would public-but-not-conformable protocols by default be the next step, then, in Swift's evolution?</div></div></div></div></blockquote><br class=""></div><div class="">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).</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><span style="color:rgb(34,34,34)" class=""></span></div></font></span></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>