<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Jul 2016, at 17:33, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello Swift community,<br class=""><br class="">The third review of "SE-0117: Allow distinguishing between public access and public overridability" begins now and runs through July 25. 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="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">Just posted in the Review #2 thread. I read the updated proposal, and I have another idea besides making “final” default:</div><div class=""><br class=""></div><div class="">I would be okay with the inferred situation for classes being a semantic “final”. That is, that they cannot be subclassed, but they won’t be automatically optimised in a fragile way either. We could call it “sealed” if you want to explicitly specify it - the difference is that it doesn’t only apply at the module boundary, and it’s just an annotation for the type-checker (both yours and that of the third-party developer) that it shouldn’t allow this - it’s not license for library module’s compiler to give up flexibility. So:<br class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">public class Foo {} // Implicitly “sealed”. Cannot be subclassed anywhere. Does not provide optimiser guarantees of “final”.</div><div class="">public(sealed) class Foo {} // as above</div><div class=""><br class=""></div><div class="">public final class Foo {} // Implicitly “sealed”. Cannot be subclassed anywhere. Allows resilience-breaking optimisations.</div><div class="">public(sealed) final class Foo {} // as above</div><div class=""><br class=""></div><div class="">public internal(open) class Foo {} // “open” overrides “sealed” for the internal scope. Cannot be subclassed externally; may be subclassed internally. Does not provide optimiser guarantees of “final”.</div><div class="">public open(internal) class Foo {} // another idea: flipping the order, so it becomes open(internal) rather than internal(open). This looks nicer, is the opposite of the property accessor scope syntax - "public internal(set) ..."</div><div class="">public(sealed) internal(open) class Foo {} // as above</div><div class=""><br class=""></div><div class="">public(sealed) internal(open) final class Foo {} // Error: A class cannot be both open and final</div></blockquote><div class=""><br class="">I believe that would meet the goals of:<br class=""><br class="">- Not allowing subclassing from external modules unless explicitly allowed (the original goal)<br class="">- Making classes which are internally-subclassed easier to locally reason about (my nice-to-have)<br class="">- Maintain binary compatibility<br class="">- Do not give up binary flexibility unless the user explicitly asks for it (a goal in the LibraryEvolution docs, however current or not they may be)<br class=""><br class="">Is there anything I missed?<br class=""><br class="">Karl</div></body></html>