> 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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
