> On Jul 15, 2016, at 10:52 PM, Chris Lattner <[email protected]> wrote:
>
> * What is your evaluation of the proposal?
I agree with the core team that closed by default for classes is the right move.
I also think that it makes sense for methods to be closed by default.
**However**, I am seriously concerned about the source-code impact of this
change. I believe there are at least an order of magnitude more public member
declarations than public class declarations in most projects. For instance, I
attempted (using crude, most likely imperfect regex-based algorithms) to
estimate the number of classes, methods, properties, and subscripts in Corelibs
Foundation, and got these results:
class: 120
func: 1277
subscript: 6
var: 707
(Note: I removed obviously incorrect things like top-level constants and
functions, but these numbers probably still count some struct and enum members.)
Annotating 120 types is not that big a deal relative to the size of Foundation.
Annotating 1,990 members introduces much more clutter and tremendously
increases the burden of closed-by-default. I don't think I can support
burdening that many declarations with extra syntax; it seems like a lot of red
tape for a case where you've already explicitly opted in to subclassing.
That's why I prefer the alternative design of having `open` as a separate
access level. I don't think it is a serious burden to have to search for
"public|open" when you want to see all public APIs. Nor do I think it's a
problem that `open` is short. A short keyword would be a problem if our goal is
to actually *discourage* subclassing, but if we merely want people to *think*
before they subclass, we should be happy that permitting subclassing and
overriding is not encumbered with heavyweight keywords.
Meanwhile, the benefits of an `open` access level are manifold:
* It ensures that unsealing is no more burdensome than sealing.
* There's no need for a "you can't declare it open because it's not public"
diagnostic.
* It defuses one of the complaints about this change from its critics, easing
acceptance.
As an alternative to having `open` as a separate access level, we could instead
have it merely imply `public`: the canonical form would be `public open`, but
source code could just say `open`. Generated interfaces would always say
`public open`, so searching for `public` in those would work as you want it to.
So, in short:
1. Yes on closed classes by default.
2. No on closed members by default, unless we use a syntax less burdensome than
`public open`.
3. I think the arguments against standalone `open` are weak, and I would
strongly prefer it to `public open`.
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes.
> * 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?
I've used OO languages, but not sealing ones.
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
Quick reading of this draft, but deep involvement in previous reviews and
discussions.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
