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

[Goffredo Marocchi]

Sent from my iPhone

> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

Maintaining a fork, realistically often without hope of upstream merging, your changes is feels like a very business unfriendly idea and less scalable than it sounds in many environments.

I see closed by default as part of the movement some people seem to be embracing of opt-out model in which freedom and versatility is forcefully restrained, making the language more complex and exotic/breaking conventions for the sake of protecting people from themselves, instead of opt-in models which require programmers to be diligent and know when to constrain themselves while enjoying more flexible defaults.
I am not asking for JavaScript, but I do not want this language to go the complete polar opposite, more dogmatic than C++ or Java.