> On 21 Jul 2016, at 17:33, Chris Lattner via swift-evolution
> <[email protected]> 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
> [email protected]
> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
