[swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Karl]

> On 21 Jul 2016, at 17:33, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> 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:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
> 
> 	https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review manager.
> 
> What goes into a review?
> 
> 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:
> 
> 	* What is your evaluation of the proposal?
> 	* Is the problem being addressed significant enough to warrant a change to Swift?
> 	* Does this proposal fit well with the feel and direction of Swift?
> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Just posted in the Review #2 thread. I read the updated proposal, and I have another idea besides making “final” default:

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:

public class Foo {}                        // Implicitly “sealed”. Cannot be subclassed anywhere. Does not provide optimiser guarantees of “final”.
public(sealed) class Foo {}           // as above

public final class Foo {}                // Implicitly “sealed”. Cannot be subclassed anywhere. Allows resilience-breaking optimisations.
public(sealed) final class Foo {}   // as above

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”.
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) ..."
public(sealed) internal(open) class Foo {}          // as above

public(sealed) internal(open) final class Foo {}  // Error: A class cannot be both open and final

I believe that would meet the goals of:

- Not allowing subclassing from external modules unless explicitly allowed (the original goal)
- Making classes which are internally-subclassed easier to locally reason about (my nice-to-have)
- Maintain binary compatibility
- 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)

Is there anything I missed?

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/74b6a325/attachment.html>