On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner <clatt...@apple.com> wrote:
> Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. 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. As a big proponent of API reviews for code that's going to end up being used by others, I think sealed-by-default forces authors to think about how their code might end up being used by others more so than more-permissive alternatives. Seeing a keyword that marks a class as unsealed is a good opportunity to start a conversation in a code review. Given that Swift tries to encourage the use of value types over reference types in many places, which can't be subclassed anyway, I don't think this change should be a significant burden. I'm in the process of implementing a fairly large library that's about 95% value types and 5% reference types. The reference types are more of an implementation detail than a hierarchy of types, so I would have them be final anyway. This is completely anecdotal, of course, but it's a testament IMO to how differently Swift has me thinking about the way I structure my APIs, and subclassing has been mostly replaced by protocol extensions and composition. I'm not compelled by the arguments that we need subclassing to fix bad APIs, because that's absolutely not what subclassing is intended for. It's a hack, and it's not a cure-all—it relies on being able to override the correct methods and inject custom behavior in the first place. The argument shouldn't be "we need open subclassing or we can't fix broken APIs"; that's a false choice. It should be "we need *something* to fix broken APIs", and that "something" should be proposed and the need for it should be argued in its own right. The ability to fix a sealed broken API does have value, but it is inherently unsafe because you might be making assumptions about pre/post-conditions that the original class author didn't think about, and those assumptions could become invalid in the future (or might rely on internal implementation details that you cannot predict). Rather than abusing a construct that is not suited for that purpose, those arguing for the need for that functionality should propose something more appropriate. This would be a win-win; we'd have a clean way of expressing API boundaries, and an unsafe-but-acknowledged-as-such way of hooking into APIs if a trap door is needed. (Of course, with Swift at such a young age, it's hard to know what the needs for that are until we have some more mature libraries to present as use cases.) > * 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. The behavior that classes are unsealed within the same module but sealed by default outside the module aligns nicely with the way internal visibility already works in the language. Newcomers and app developers don't have to think about it, but those who want to release code for others to use must; I think that's the right level of responsibility. > * 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 proposal and followed the heated discussion in the review thread. > > 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-announce mailing list > swift-evolution-annou...@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution-announce >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
