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

Matthew Johnson matthew at anandabits.com
Sat Jul 9 11:29:32 CDT 2016


> On Jul 9, 2016, at 11:04 AM, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> Of course it can be done either way.  But there are significant ecosystem robustness advantages to making sealed the default and comparatively few downsides.  Most libraries are open source (so can be modified directly or via PR if necessary)
> First:
> The claim about robustness sounds like a fact, despite being just an opinion (feel free to correct me if you have any evidence at all). We should stay honest with our predictions.
> Second:
> Do you really believe there will be positive impact on open-source libraries?
> My forecast is that closed by default will dramatically increase trivial pull request where developers ask for unsealing so that they can do as they likeā€¦

I think this is a good thing.  It will force a considered answer and a discussion about whether or not subclassing should be supported by the library.  

> and I've no idea why somebody could come up with the idea that forking is desirable.

Forking is desirable if your goals, needs, values, etc are substantially different than the library author such that you do not agree on what the API contract should look like.




More information about the swift-evolution mailing list