<div dir="ltr">On Sat, Jul 16, 2016 at 9:09 AM, David Hart via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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>Swift has always gone towards making declarations explicit to read. Having open on thé class declaration makes it so you don'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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>2016/07/16 21:37、Jean-Daniel Dupas <<a href="mailto:mailing@xenonium.com" target="_blank">mailing@xenonium.com</a>> のメール：</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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> のメッセージ:</div><div><br></div><blockquote type="cite"><div><span>FWIW, I'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'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't expose any members: it would then just be subclassable.</div><div><br></div><div>If the act of making the class open doesn't implicitly make overriding possible, well all you can do then is add methods, and that can be done with extensions anyways, so it'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 'open' itself may imply 'hey I'm open, please do what you want with my public members', whereas 'subclassable' is more specific in intention... (but that'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 'final' keyword.</div><div><br></div><div>If we were to default to non-overridable, a more consistent 'open' 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 'open' is available for both class and method there… I suppose its the whole "default to safe", just in case someone made one method 'open' 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>: "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."</div></div></blockquote><div><br></div></span><div>I'm fairly sure that does not apply to open as it's fairly orthogonal to other access control modifiers.</div></div></blockquote><div><br></div><div>I agree that the statement in SE-0025 by itself doesn't necessary apply to `open` because they are somewhat orthogonal. But the stated rationale in SE-0025 applies equally to `open`, so I think this proposal would be improved by having `open` behave similarly in this respect. Here's why:</div><div><br></div><div>The rationale stated in SE-0025 is that it allows a person who controls the type to design as though it will have broader access than it actually does. For instance, I can design an internal class as though it will be public, and when I'm satisfied with it, I can flip the switch and actually make it public by adding a single access modifier. That rationale falls down for classes if I cannot design a `public open` class without already making it `public open`. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><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></div>