<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=""><div><blockquote type="cite" class=""><div class="">Le 16 juil. 2016 à 00:31, Andre Elder via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""><span class=""></span></div><div class=""><div class=""><span class=""></span></div><div class=""><div class="">2016/07/15 16:37、Riley Testut via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">FWIW, I'm still against this proposal, but since it will be accepted regardless, here are my thoughts:</span><br class=""><span class=""></span><br class=""><span class="">• Open keyword is significantly better. </span><br class=""><span class="">• 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 class=""></div></blockquote><div class="">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 class=""><br class=""></div><div class="">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 <i class="">public open class {}</i> pattern <i class="">just</i> by itself not so useful imho... 😬</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class="">Do we really need an open keyword ?<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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><br class=""></body></html>