[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell]

> * What is your evaluation of the proposal?

+1, with bikeshedding.

To me, “subclassable” does not imply “public.” If I hadn’t read this proposal, I would be likely to declare an internal class subclassable, and then be shocked when it was exposed as public!

If it’s part of my public API, I want to see the word “public” on it. That should not be implicit under any circumstances. I strongly prefer any one of these to the standalone “subclassable:”

	• public(subclassable)
	• public(open)
	• public(extensible)

The extra verbosity is tolerable because subclassability by design is (should be!) the exception, not the rule.

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

Yes, it fits two patterns of Swift’s general design:

if one choice is the default, it is the safer one; and
consequential design decisions are explicit. Implicitness is reserved for obvious / redundant information that becomes noise and interferes with readability.

To that end…

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

…open public classes run against general precedent in the language, so yes.

As programmers grow used to Swift, they will increasingly lean on the compiler to prompt them when there is an important type design issue to consider, or when they are doing something that compromises type safety. The absence of a compiler warning becomes important information.

This means that making open classes the default is not just aesthetically suboptimal; it is actively misleading.

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

No. In all the OO languages I’ve used, classes are open by default. That raises a question: is this really a good idea? Aren’t we ignoring established precedent? What about all the unauthorized subclassing we’ve done in the past?

I’m sympathetic to those accustomed to Objective-C, Ruby, Javascript, Python, and other languages with more fungible type systems who argue that it’s unreasonable to expect us all to use classes only as library authors intend. Monkey patching has saved many a day, they’d say. And it’s true, it has! I rely on it.

My counterargument: the ecosystem is changing.

In the era of increased open sourcing, easy forking, and more community-driven development, this concern is less severe than it used to be. I rarely use any closed-sourced libraries for iOS development. If I need to tweak some library and non-subclassibility is getting in the way, then I can fork it — and perhaps even contribute my changes back to improve the upstream project. In an open source world, “closed by default” makes a lot more sense.

The big exception to this is Apple itself, and the direction of this proposal implies a large cultural shift in how Apple deals with its developer community. Having the Swift language so aggressively prevent the dubious, brittle, bad-idea-but-it-gets-the-job-done workarounds that the Obj-C runtime allowed means that Apple’s platforms are going to have to be more consciously extensible, more transparent in their design decisions, and more responsive to unanticipated needs. This community right here is an exemplar.

Here’s thing: this big shift goes far, far beyond this proposal. Swift already rules out most any form of messing with a library’s assumptions about its own design. With or without the proposal, Apple is already getting on board with the new regime of stricter typing and more hermetically sealed libraries. They’re already going to have to make API design decisions about how and where extensibility is allowed with unprecedented caution.

This proposal hardly alters that tipping balance; it just removes a design inconsistency.

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

I read the proposal carefully, the discussion thread not at all.

Cheers,

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/e741430d/attachment.html>