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

[Tino Heth]

> 1. As you point out, the majority of the surface area of idiomatic Swift APIs are unlikely to be impacted (value types, protocols, and final classes).  This is very likely to apply to future Swift-native APIs from Apple regardless of the outcome of this proposal.
> 
> 2. There is no impact on users of Apple's Objective-C APIs (AFAICT).
> 
> In the context of these facts, this proposal is not nearly as dramatic a change as many seem to be suggesting.
It is dramatic, and your whole argument is flawed because you miss the imho most important point.
This is not only a question of "will I be able to override this tiny method of UIView in the future?", but a question of attitude:
When you do away with the rule of lenity and change it to "guilty by default", the direct impact is marginal as well — but it is a drastic change for the society as a whole.

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.
When you use a library in a way that wasn't anticipated by its author, you'll ran into issues occasionally; nonetheless, I think we should struggle for an open ecosystem that encourages others to experiment and fail, rather than to limit their possibilities in a futile attempt to protect them.

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"?
As a matter of fact, open by default forces nobody to subclass and override, so it's easy to avoid any problems caused by excessive hacking — closed by default, on the other hand, has impact not only on those who believe in restrictions, but on those who dislike them as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/68892368/attachment.html>