This is the case with a library. It is *not* the case with a framework. Dynamically linked frameworks can be changed without the app even being changed. Imagine if Apple changed UIKit and make UINavigationController final retroactively. UIKit internally would therefore call directly to the UINavigationController methods statically, and bypass any subclass’s methods, thereby breaking applications. Should app apps have to be rebuilt to work with iOS 12 simply because Apple shipped a new version of UIKit? This is illogical. You will *break* things by finalising after the fact. Swift, being about safety, needs to deal with this safely.
> On 11 Jul 2016, at 9:13 AM, Tino Heth <2...@gmx.de> wrote: > > >> 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
