> If you have a ParentClass and a SubClass, and the ParentClass is sealed while > the SubClass is subclassable. What happens? No matter how this question is > answered, I don't like the answer. (compile error => bad. || make it as the > user wishes => bad; what do we gain by letting ParentClass remain sealed? || > make ParentClass implicitly subclassable too => bad.) I'm happy that there are not only supporters for this proposal, but imho the example is no compelling argument: With no doubt, I'd expect I can subclass only SubClass — like I can't instantiate an abstract class, which is just fine for its children. ParentClass might do some dangerous things that don't happen in SubClass, so there might even be a use-case (but imho it would be better if I could mark ParentClass as internal in this situation).
But imho there is another aspect I haven't read about yet: "final by default" would have had direct impact on any developer, while this proposal merely changes things for those who create libraries… So, the question is: How will those be build? If you live in a world of secrets and non-disclosure, I can understand that sealed is desirable — but that's not the future I want to see, and github is a good indication that others share this opinion. If you share the sympathy for Open source, the two scenarios are as follows: We stick with "open by default"; users of libraries will use them in ways that the creator hasn't thought of before, and bugs will show up. But: We know how to deal with bugs, that's our job! So in the best case, we find the reason for the bad behavior, create a pull request, and everyone is happy. With "sealed by default", the situation changes: Users are protected from some simple bugs, but nonetheless, they'll encounter situations where the library doesn't do exactly what they want. So, you take a look at the source, find the problem, and fix it. It's no bug at all, it's just a tiny degree of freedom that is missing because it wasn't important to the author. You can create a pull request as well, but it doesn't offer a real improvement to the author, who is already busy with dozens of similar requests by other users -> you end up with a custom branch with all the housekeeping associated with it. So overall, I'm quite sure that the proposal won't improve software quality, but rather degrade it. Tino _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
