<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 dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><font size="2" class="">This has been a very interesting and educational thread.</font></div><div class=""><font size="2" class="">Thanks to everyone who kindly replied to me and explained things.</font></div><div class=""><span style="font-size: small;" class=""><br class=""></span></div><div class=""><span style="font-size: small;" class="">Here is my 2¢</span><font size="2" class="">…</font></div><div class=""><span style="font-size: small;" class=""><br class=""></span></div><div class=""><blockquote type="cite" class=""><pre class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);"><font size="3" class=""> * What is your evaluation of the proposal?
</font></pre></blockquote><div class=""><font size="2" class="">+0 as it stands… </font></div><div class=""><span style="font-size: small;" class="">+1 if there could be a reliable way for us to explicitly un-seal a sealed class for those times where its </span><i class="">absolutely</i><span style="font-size: small;" class=""> necessary.</span></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">If its at all feasible… maybe something like ...</font></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><div class="gmail_default"><pre style="margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51); background-color: rgb(247, 247, 247);" class=""><div class="gmail_default" style="color: rgb(0, 0, 0); font-family: Helvetica; white-space: normal;"><pre style="margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class=""><div style="color: rgb(51, 51, 51); margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""><span style="-webkit-font-kerning: none; color: rgb(167, 29, 93);" class="">public</span><span style="-webkit-font-kerning: none;" class=""> </span><span style="-webkit-font-kerning: none; color: rgb(167, 29, 93);" class="">class</span><span style="-webkit-font-kerning: none;" class=""> MyWorkaroundClass : @forceOpen(YourSealedClass) { //Obligatory Compiler Warning Occurs </span></font></div><div style="margin: 0px; line-height: normal;" class=""><span style="-webkit-font-kerning: none;" class=""><font face="Menlo" class=""><span style="color: rgb(51, 51, 51);" class=""> </span><font color="#a71d5d" class="">public</font><span style="color: rgb(51, 51, 51);" class=""> </span><font color="#a71d5d" class="">override</font><span style="color: rgb(51, 51, 51);" class=""> </span><font color="#a71d5d" class="">func</font><span style="color: rgb(51, 51, 51);" class=""> </span></font></span><span style="color: rgb(51, 51, 51); font-family: Menlo; white-space: normal;" class="">@forceOpen(</span><span style="color: rgb(51, 51, 51); font-family: Menlo; white-space: normal;" class="">brokenFunc()</span><span style="color: rgb(51, 51, 51); font-family: Menlo; white-space: normal;" class="">)</span><span style="color: rgb(51, 51, 51); font-family: Menlo; white-space: normal;" class=""> {/*FIXME*/}</span></div><div style="color: rgb(51, 51, 51); margin: 0px; line-height: normal;" class=""><span style="-webkit-font-kerning: none;" class=""><font face="Menlo" class="">}</font></span></div></pre></div></pre></div></div><div class="gmail_default"><font size="2" class=""><font face="arial, helvetica, sans-serif" class="">(The above is just a rough idea, please don't yell at me for the ugliness... 🙂)</font></font></div><div class="gmail_default"><font style="font-family: arial, helvetica, sans-serif;" size="2" class=""><br class=""></font></div><div class="gmail_default"><font style="font-family: arial, helvetica, sans-serif;" size="2" class="">Just like we have forced unwrapping of optionals (for only when we <i class="">really</i> </font><span style="font-family: arial, helvetica, sans-serif; font-size: small;" class="">need</span><font face="arial, helvetica, sans-serif" class=""> </font><font face="arial, helvetica, sans-serif" size="2" class="">it), I believe that we should be able to force unseal when we truly need it;</font></div><div class="gmail_default" style="font-family: arial, helvetica, sans-serif;"><font size="2" class=""><br class=""></font></div><div class="gmail_default"><font size="2" class=""><font face="arial, helvetica, sans-serif" class="">Another +1 if the keyword is changed from subclassable/overridable to something less confusing… since people might be easily be misled and think that even within thier own module if they don't mark it subclassable it won’t be subclassable… perhaps "open" is the better keyword</font></font><font face="arial, helvetica, sans-serif" size="2" class="">…</font></div><div class="gmail_default"><br class=""></div><div class="gmail_default"><div class="gmail_default"><pre style="margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51); background-color: rgb(247, 247, 247);" class=""><div class="gmail_default" style="color: rgb(0, 0, 0); font-family: Helvetica; white-space: normal;"><pre style="margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class=""><div style="color: rgb(51, 51, 51); margin: 0px; line-height: normal;" class=""><font face="Menlo" class=""><span style="-webkit-font-kerning: none; color: rgb(167, 29, 93);" class="">public o</span></font><span style="color: rgb(167, 29, 93); font-family: Menlo; white-space: normal;" class="">pen</span><span style="font-family: Menlo; white-space: normal; -webkit-font-kerning: none;" class=""> </span><span style="font-family: Menlo; white-space: normal; -webkit-font-kerning: none; color: rgb(167, 29, 93);" class="">class</span><span style="font-family: Menlo; white-space: normal; -webkit-font-kerning: none;" class=""> MyOpenClass { </span></div><div style="margin: 0px; line-height: normal;" class=""><span style="-webkit-font-kerning: none;" class=""><font face="Menlo" class=""><span style="color: rgb(51, 51, 51);" class=""> </span><font color="#a71d5d" class="">public</font><span style="color: rgb(51, 51, 51);" class=""> </span></font></span><font face="Menlo" style="white-space: normal; color: rgb(51, 51, 51);" class=""><span style="-webkit-font-kerning: none; color: rgb(167, 29, 93);" class="">o</span></font><span style="color: rgb(167, 29, 93); font-family: Menlo; white-space: normal;" class="">pen</span><span style="font-family: Menlo; white-space: normal; color: rgb(51, 51, 51);" class=""> </span><font color="#a71d5d" style="font-family: Menlo; white-space: normal;" class="">func</font><span style="font-family: Menlo; white-space: normal; color: rgb(51, 51, 51);" class=""> openFunc() {/*OVERRIDE ME!*/}</span></div><div style="color: rgb(51, 51, 51); margin: 0px; line-height: normal;" class=""><span style="-webkit-font-kerning: none;" class=""><font face="Menlo" class="">}</font></span></div></pre></div></pre></div></div><div class="">In this case, "open" can only apply to public classes/methods/accessors, anything else using "open" ("private open" etc) will be an obvious error.</div><div class=""><br class=""></div><i class="">Please note that I am not against this proposal in theory; only that I would humbly request that the two items above be at least considered and I will happily jump on board.</i></div><div class=""><br class=""><blockquote type="cite" class=""><pre class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);"><font size="3" class=""> * Is the problem being addressed significant enough to warrant a change to Swift?
</font></pre></blockquote><div class=""><font size="2" class="">I do think it is, because the potential upsides are many, such as better fencing between modules and users of those modules, <i class="">potential</i> performance gains and making it more explicit to a library writer what he/she is going to make public and also modifiable by consumers of the provided API.</font></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">Again though, I would be reticent to agree 100% if there werent a way to punch though that fence when we need to, not allowing such a thing makes the environment too rigid/unproductive and thats not the Swift I want to continue using. Swift is not C++ minus the C… is it?</font></div><font size="2" class=""><br class=""></font><blockquote type="cite" class=""><pre class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);"><font size="3" class=""> * Does this proposal fit well with the feel and direction of Swift?
</font></pre></blockquote><div class=""><font size="2" class="">I think overall it does because swift encourages more ad-hoc composition than inheritance based, so making inheritability more explicit does seem to fit in with the direction of Swift… although the lack of ability to escape that limitation just like we have with forced unwrapped optionals makes me feel its at the same time not fully in line with the direction of swift… hence the +0 instead of a full +1.</font></div><div class=""><br class=""></div><blockquote type="cite" class=""><pre class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);"><font size="3" class=""> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
</font></pre></blockquote><font size="2" class="">Someone here brought up Kotlin, but I have only dabbled with it.. It seems similar to that from what I can read… but I have no experience with writing or consuming a library in Kotlin.</font></div><div class=""><font size="2" class=""><br class=""></font><blockquote type="cite" class=""><pre class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);"><font size="3" class=""> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
</font></pre></blockquote></div><div class=""><pre class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);"><font face="Helvetica" size="2" class="">I have been wrestling with this in my mind since late last year when it first appeared on the swift-evolution list as a general discussion. </font></pre><pre class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);"><font face="Helvetica" size="2" class="">I was originally very very strongly -1 on this (especially coming from an Objective-C background), but after reading the proposal and everyones replies both for and against, and thinking again deeply about my own code, have come around to believe that there are potential gains for this that are worthwhile, but only if some flexibility remains in the language to work around classes that are both closed-source and has a defect that is needed to workaround though subclassing.</font></pre></div><div class=""><div class=""><font size="2" class="">——</font></div></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">Pros</font></div><div class=""><ul class=""><li class=""><span style="font-size: small;" class="">Better Fencing Between Modules</span></li><li class=""><span style="font-size: small;" class="">Potential Performance Gains</span></li><li class=""><font size="2" class="">Subclassing is Discouraged Unless its Explicitly Thought About</font></li></ul></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">Cons</font></div><div class=""><ul class="MailOutline"><li class=""><span style="font-size: small;" class="">Unable to Override a Method/Accessor on a Class that Needs Fixing but is </span><span style="font-size: small;" class="">Closed Source</span><span style="font-size: small;" class=""> </span></li><li class=""><font size="2" class="">You are at the <i class="">total</i> mercy of the framework author… (this one is pretty big to be honest)</font></li></ul></div><div class=""><font size="2" class=""><span class="Apple-tab-span" style="white-space:pre"> </span></font></div><div class=""><br class=""></div><div class="">"Unknowns" that make it hard to judge...</div><div class=""><br class=""></div><div class=""><div class=""><ul class="MailOutline"><li class=""><font size="2" class="">What effect this will <i class="">really</i> have on the community… </font></li><li class=""><font size="2" class="">What <i class="">true</i> objective performance benefits we can expect from inter-module optimization…</font></li><li class=""><font size="2" class="">Will this <i class="">really</i> make libraries any better?</font></li></ul><div class=""><br class=""></div></div></div><div class=""><br class=""></div><div class=""><div class=""><font size="2" class="">——</font></div></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">Other thoughts...</font></div><div class=""><ul class=""><li class=""><font size="2" class="">While it can be said that because most libraries are open source, the need to subclass is lower now than ever -we can just go in and fix something and send a pull request- </font><font size="2" class="">those of us trapped in large corporations that have</font><span style="font-size: small;" class=""> </span><span style="font-size: small;" class="">(usually <i class="">poorly supported</i>) </span><span style="font-size: small;" class="">SDKs shoved down our throats by the suits need a certain level of flexibility to work arounds things</span><font size="2" class="">… <br class=""><br class=""></font></li><li class=""><font size="2" class="">In debating to support this or not, I am reminded of comments by many here: <a href="http://mjtsai.com/blog/2015/12/21/swift-proposal-for-default-final/" class="">http://mjtsai.com/blog/2015/12/21/swift-proposal-for-default-final/</a></font></li></ul><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">——</font></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">Thanks,</font></div></div><div class=""><font size="2" class=""><br class=""></font></div><div class=""><font size="2" class="">Andre</font></div><div class=""><font size="2" class=""><br class=""></font></div><font size="2" class=""><br class=""></font><div><blockquote type="cite" class=""><div class=""><font size="2" class="">2016/07/06 8:11、Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメール：</font></div><font size="2" class=""><br class="Apple-interchange-newline"></font><div class=""><div class=""><font size="2" class="">Hello Swift community,<br class=""><br class="">The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a><br class=""><br class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class="">or, if you would like to keep your feedback private, directly to the review manager.<br class=""><br class="">What goes into a review?<br class=""><br class="">The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""><br class="">More information about the Swift evolution process is available at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://github.com/apple/swift-evolution/blob/master/process.md<br class=""><br class="">Thank you,<br class=""><br class="">-Chris Lattner<br class="">Review Manager<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></font></div></div></blockquote></div><br class=""></div></body></html>