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

[Paul Cantrell]

> On Jul 8, 2016, at 12:30 PM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Defaults matter, because they transmit a message:
> Every rule and obstacle we add to Swift is a statement that says "we favor bureaucracy over freedom", and this will affect the community evolving around the language.

…or “we favor mindfulness over carelessness,” or “we favor static type safety over runtime bug discovery.”

There are many ways of recoloring that thought.

> Everyone should ask himself a simple question:
> When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?

The correct question is:

When was the last time you thought, “I really wish the author of that library had thought carefully about where and how they expected people to extend it?”

I spend a lot of time in the Ruby world as well, where there is no static type safety at all, and the entire type structure of your program and all of its libraries is open for rewiring the whole time the program is running. And you know what? It works just fine in practice! I’d say it favors rapid prototyping at the expense of subtle bugs staying hidden longer than they otherwise might. That’s a tradeoff that’s worth it for many projects. Pros and cons aside, though, people build good software this way. Ruby’s “nothing is sealed, everything is Play-Doh” approach really does work in practice.

The interesting question is not _whether_ this works, but _why_ it works. Ruby coders know not to expect any correctness help from the compiler, and know what kinds of testing they need to do to verify that correctness by other means. They build systems with the expectation of unit correctness being no guarantee of integrated system correctness. An entire ecosystem of culture, habit, and expectations supports the language’s looseness.

Swift already — today, right now, even without this proposal — sets very different expectations. Developers _do_ expect certain kinds of help from the compiler. In particular, they expect that consequential design decisions are explicitly declared, and that where is is a default, it is the one that favors static verification. Subclassibility is a consequential design decision, and it is one that precludes certain kinds of static verification (because how overriding methods can break encapsulation). Making it the default thus contradicts the developer expectations that the language has already established.

The question is not whether sealed or open is the One True Way. The question is which fits into Swift’s particular ecosystem of culture, habit, and expectations.

This is engineering, folks. No gospel truths here; it’s all tradeoffs. Open by default can be the right tradeoff for one language, and the wrong one for another.

Cheers,

Paul