<div dir="ltr">What happens if I want an `internal` subclass of an `open` class? </div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 16, 2016 at 10:09 AM, David Hart via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Swift has always gone towards making declarations explicit to read. Having open on thé class declaration makes it so you don&#39;t have to go hunting into its members to see if it contains an open member.</div><div><br></div><div>Other comments inline:</div><span class=""><div><br>On 16 Jul 2016, at 14:49, Andre 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><br><div><blockquote type="cite"><div>2016/07/16 21:37、Jean-Daniel Dupas &lt;<a href="mailto:mailing@xenonium.com" target="_blank">mailing@xenonium.com</a>&gt; のメール:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div>Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :</div><br><div><div dir="auto"><div><span></span></div><div><div><span></span></div><div><div><span></span></div><div><div>2016/07/15 16:37、Riley Testut via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; のメッセージ:</div><div><br></div><blockquote type="cite"><div><span>FWIW, I&#39;m still against this proposal, but since it will be accepted regardless, here are my thoughts:</span><br><span></span><br><span>• Open keyword is significantly better.<span> </span></span><br><span>• Members should be *open* by default, and final should be opt-in. If you&#39;re opening up a class for subclassing, my gut says you should allow the client to do as they wish.</span><br></div></blockquote><div>If you have a class that was not open yet, just making it open wouldn&#39;t expose any members: it would then just be subclassable.</div><div><br></div><div>If the act of making the class open doesn&#39;t implicitly make overriding possible, well all you can do then is add methods, and that can be done with extensions anyways, so it&#39;s not as useful and makes the<span> </span><i>public open class {}</i><span> </span>pattern<span> </span><i>just</i><span> </span>by itself not so useful imho... 😬</div><div><br></div><div>Also, the keyword &#39;open&#39; itself may imply &#39;hey I&#39;m open, please do what you want with my public members&#39;, whereas &#39;subclassable&#39; is more specific in intention...  (but that&#39;s just me, so n=1 and all that)</div><div><br></div><div>TLDR; +1 to the above: simpler is better and defaulting to overridable for public members on an open class is simpler... invariants can be protected by the &#39;final&#39; keyword.</div><div><br></div><div>If we were to default to non-overridable, a more consistent &#39;open&#39; on the method is preferred over overridable for me... open class, open method... much better imho...</div></div></div></div></div></div></blockquote><br>Do we really need an open keyword ?<div><br></div><div>As already said, if open does nothing more than allowing the class to be subclassed, why not simply make the class subclassable if it contains at least one overridable member ?</div></div></div></blockquote><div>Thats a good point actually… but looks like Review #2 has already started… and &#39;open&#39; is available for both class and method there… I suppose its the whole &quot;default to safe&quot;, just in case someone made one method &#39;open&#39; they may not have intended to actually make the whole class open… (also see below)</div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div>In case we require an open keyword, what would happen if someone mark a member overridable, but does not make the class open ? Will the compiler emit an error, or make the class implicitly « open » ? </div></div></div></div></blockquote></div>In proposal #2 looks like it would generate an error, but Xiaodi Wu has said that it should be allowed and not generate an error per <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" target="_blank">SE-0025</a>.<br><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#complications-with-private-types" target="_blank"></a><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#complications-with-private-types" target="_blank">Take a look at</a>: &quot;The compiler should not warn when a broader level of access control is used within a type with more restrictive access, such as internal within a private type.&quot;</div></div></blockquote><div><br></div></span><div>I&#39;m fairly sure that does not apply to open as it&#39;s fairly orthogonal to other access control modifiers.</div><br><blockquote type="cite"><div><div><div>- Andre</div></div></div></blockquote><span class=""><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></span></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>