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

[Tino Heth]

> The problem with this is simple: you cannot retroactively "close up" an API. I cannot add final to a class I have previously declared as non-final. I also can seal a class which has previously been open to subclassing.
Of course you can do both — it may make users angry, but so what?
The essence of this way of thinking is "I fear the reaction of my users when I take something away from them… so I have to deny them those options right from start".

I've no statistics (there's a general lack of facts all over the place…), but I don't thing the majority of todays and future libraries are build with a strictly planned top-down approach and guarantees about API-stability. Nowadays things are much more spontaneous, and the strict rules and limits some people here want to force upon others would most likely decrease the joy in playing with the language and start experiments in it.

There is only a very small number of Swift-developers writing frameworks that are used on a large scale basis, and even if many people in this group vote for limiting defaults, the focus should be on the majority:
When I come to the conclusion that a set of classes in a project could be useful somewhere else, my problem is not fear of future API changes — it is the daunting task of having to sprinkle "public" all over the place.
Sealing classes makes proper code reuse a more tedious job, and I want Swift to stay fun rather than become a playground for sticklers for order.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/73ac6b56/attachment.html>