<div dir="ltr">On Mon, Jul 18, 2016 at 2:59 AM, Goffredo Marocchi <span dir="ltr">&lt;<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>&gt;</span> wrote:<br><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 dir="auto"><div>Hello Xiaodi,</div><div><br></div><div><span class=""><blockquote type="cite"><span style="background-color:rgba(255,255,255,0)">A general principle of Swift, recently strengthened by proposals such as <a href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0117-non-public-subclassable-by-default.md" style="text-decoration:none" target="_blank">SE-0117</a>, has been that public API commitments should require explicit opt-in. Given the different behavior of classes and structs, the fact that extensions allow public methods to be declared without spelling out <code style="padding:0.2em 0px;margin:0px;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">public</code> at the declaration site has been called &quot;confusing&quot; or &quot;odd.&quot;</span><br></blockquote><div><br></div></span><div>I think this is slightly misleading as that proposal dealt with classes being sealed by default outside of the current module while from your summary this would be also an explicit call for final by default which is not something the core team said explicitly or that the Swift community largely agrees with.</div></div></div></blockquote><div><br></div><div>Sorry, I will edit to clarify that sentence. My thinking was, Swift is already internal by default; SE-0117 has added another layer, so that it&#39;s internal -&gt; public -&gt; public open. In my mind, that&#39;s strengthening in that the opt-in process for public APIs is now even more fine-grained.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br>Sent from my iPhone</div><span class=""><div><br>On 18 Jul 2016, at 08:50, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>A general principle of Swift, recently strengthened by proposals such as <a href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0117-non-public-subclassable-by-default.md" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank">SE-0117</a>, has been that public API commitments should require explicit opt-in. Given the different behavior of classes and structs, the fact that extensions allow public methods to be declared without spelling out <code style="font-family:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">public</code> at the declaration site has been called &quot;confusing&quot; or &quot;odd.&quot;</div></blockquote></span></div></blockquote></div><br></div></div>