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

[Nevin Brackett-Rozinsky]

>
> *What is your evaluation of the proposal?*


Strong +1 to either design, and neutral between them.

In the prior review I advocated that `open` should *only* apply to classes,
not members. This new proposal turns that on its head and is *vastly
superior*. Tagging open members with *just* the word `open`, eliding
`public` entirely, is a phenomenal improvement.

Kudos to the core team both for crafting this solution, and more
importantly for conducting the (lengthy!) review process with such aplomb.
It would have been easy (and tempting!) to end the first review by
“accepting with revision”, leaving us with needless boilerplate and a
suboptimal design. By instead inviting the community to bikeshed a second
time *with the constraint that `sealed` would be the default*, and then
meeting afterward to thoroughly discuss the possibilities, the core team
has truly demonstrated how an *ahem* open, public design process ought to
be carried out.


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


Honestly I am not in a position to say.


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


Well, the one aspect I am not sure about is, “A class member that overrides
an open class member must be explicitly declared open unless it is
explicitly final or it is a member of a final or non-public class. In any
case, it is considered open.”

This seems like an unnecessary restriction. Perhaps I want to override an
`open` member with a `public` one. As in,

open class Base { open var x: Int { return 6 } }
open class Sub: Base { public var x: Int { return 7 } }
open class Grand: Sub { final var x: Int { return 8 } }

Note that “Sub” might be defined in a separate module from “Base”, a module
that wants to publish Sub and Grand without letting its own clients
override `x` from them.


*If you have used other languages or libraries with a similar feature, how
> do you feel that this proposal compares to those?*


Only languages with run-of-the-mill access control, nothing like this!


*How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?*


I read all messages in the previous draft and review threads, and the
entire new proposal except for the 8-paragraph, 886-word “Motivation”
section. Seriously, that is 3½ pages of motivation!

Nevin


On Thu, Jul 21, 2016 at 11: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?
>         * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/1ac6d906/attachment.html>