Two days ago, I challenged the supporters of this proposal to show a singe persuasive example to illustrate that this proposal could actually improve something. I got a single reply — which did not contain an example, but just the claim that there is one… Imho that alone should be enough to cancel the whole thing, because even if there are cases which cannot be repelled with the simple advice "just don't subclass", this would only be a basis to start talking about the actual pros and cons.
So for me, the promised benefits are less likely than the existence of Bigfoot: I guess there are at least several hundred people who swore they have seen him, and there are even some blurry photos ;-) Of course, it is impossible to come up with an unquestionable argument for the change — and it's also impossible to prove the opposite, because the whole debate makes as much sense as arguing wether raisins are tasteful or terrible; it's nothing but personal preference, and the only thing we can hope for is that the bias of those who will decide this proposal isn't at odds with the needs of the majority. If we can agree that it is not about facts, but about opinion, there are still fundamental arguments against SE-0117: Those who have issues with subclassing can just resign from it (as users of a library), and they can annotate their classes to dictate their usage (as an author) — but if you think subclassing is still a good tool, you can't do anything with a sealed class. Additionally, please note that those who ask for stricter rules and more regulation have many reasons to be happy with the status quo: You can subclass neither structs nor enums, and by default, you can't inherit from a framework-class as well, because it is internal — and yet they yell for more. Swift claims to be opinionated, not to aim for compromise — but if plain old OO isn't compatible with the ideals of the language, it would be more honest to just completely remove inheritance instead of slowly crippling it's possibilities. - Tino _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
