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

[Rod Brown]

Resent for Swift Evolution:

With the existence of Swift on the server, dynamically linked, independently distributed frameworks will not be an Apple-only issue - this extends beyond Apple's OS X-based platforms towards how dynamic frameworks link against each other as if they are to be distributed separately.

It is short sighted to suggest that all Swift deployments will be under Apple's control.

On 11 Jul. 2016, at 3:43 pm, Tino Heth <2th at gmx.de> wrote:

>> 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. 
> Your argument is true, and you choose a good example — but it's actually the only one that exists at all:
> There are no other parties that ship frameworks that way, and I don't think this should change.
> 
> So the benefits of this proposal would exist for Apple alone, and I can understand why sealed is convenient for an UIKit-engineer.
> It is tempting to aim for the easiest solution, but it is smarter to take the route that's better for the customer (and we happen to be the customers).
> And, as others pointed out before, Cupertino is free to diverge from the defaults in either direction, so it is only a little effort to have "sealed by default" without the bad side effects.