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

[Gwynne Raskind]

> On Jul 16, 2016, at 00:52, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 	* What is your evaluation of the proposal?

With all respect to those who have put a lot of work into this proposal, I’m reluctantly and immensely against it.

The reasoning from the core team that working with vendors replaces the ability to subclass to work around problems simply doesn’t hold water for me. This is a very real and very common issue, and there are endless cases where vendors won’t or even *can’t* solve the problem, especially in closed-source code. And it’s not just a matter of GUI applications; I’ve run into the need to subclass (especially in order to deliver working results in reasonable time) in projects as low-level and open-source as LLVM.

In short, saying "filing a bug will work" isn’t good enough to justify locking out the ability of developers to deal with problems in vendor code. It’s simply not true - it’s certainly almost never been true of Apple frameworks, and even when it has, that doesn’t help anyone "now". (To be clear, I’m not suggesting Apple is unresponsive to Radars. However, I am saying that there’s no transparency, no confidence in getting fixes, and no hope of any kind of reasonable (from a local perspective) timeline for deployment of fixes.)

In a perfect world, I agree this would be the case and *then* this proposal would be a fantastic concept that I’d be completely behind. Unfortunately, this is not a perfect world and the gains in encouraging good design and cleanliness of applying LSP (among other things) do not make up for the burden of implementation time and cost on framework users.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. But the change is too extreme and the ugly truth of the real world makes this proposal an inferior solution.

> 	* Does this proposal fit well with the feel and direction of Swift?

Absolutely. If not for the practical considerations, I’d love it! Conceptually speaking, I find it elegant, even harmonious. But again, in practice, the result isn’t so pretty.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Denial of subclassing has always been opt-in in ever other language I’ve used (C++ and Java, to name two, and Objective-C (and older C++) don’t even have that much). Sealing a class against subclassing is one thing, but not providing any kind of escape hatch, any kind of IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, hamstrings all users of the code. Opt-in sealing at least constrains this scenario to places where the framework writer thought it was worth adding the extra protection against horrible horribleness.

For example, it makes sense to seal NSSomeCryptographicInterface because you’re making it that much harder for something to deliberately interfere with or accidentally break crypto. It makes less sense to seal NSSplitViewController - I’d much rather Apple just said "tough noogies, your subclass breaks in this version because you did something unsupported" when fixing bugs!

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve been watching the discussion on this topic back and forth for some time now, and I read both revisions of the proposal carefully. I’m very much conceptually in favor of it, and I regret that I can’t stand behind it! But the fact remains that I think it’s a bad idea.

-- Gwynne Raskind