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

[Tony Allevato]

On Thu, Jul 21, 2016 at 8:33 AM 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?
>

+1 to the first design. I wouldn't be upset if the second design was what
got accepted, but I strongly prefer the first.

One of the benefits of this proposal has been formalizing some software
design notions related to type extensibility, and I feel very strongly that
API authors should be forced to make a decision one way or the other at the
time that they design a class whether it is extensible or not. It's true
that under design #2 you get a closed class (module extending with data)
without the explicitness of the keyword. However, being able to look at a
class definition and know immediately whether it's intended to be open or
closed is even more important. The performance improvements also seem
compelling.

While the formal side of me really liked keeping orthogonal concepts
(visibility vs. extensibility) separate, I can appreciate the desire to
eliminate boilerplate. Having "open" imply "public" unless stated otherwise
seems like a reasonable compromise.

Likewise, open-within-a-module-and-closed-outside as the default for
"public" is entirely aligned with Swift's other default visibility,
internal-by-default. The credo is essentially "don't protect users from
themselves and don't make coding more difficult for the common case of
within-app/module development, but the minute you decide to expose
something for other users, you must think about these things that affect
how others can and will use it."



>         * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Yes. More mainstream languages need to do more to encourage authors to
think about their designs and to allow those who care deeply about API
design to express them well.


        * Does this proposal fit well with the feel and direction of Swift?
>

Yes.



>         * 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?
>

Read the original and latest proposals and followed the discussions.


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/34552ffb/attachment.html>