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

[Garth Snyder]

Strong -1 from me.

I think most of my thoughts on this have already been well covered by others. I’ll just note that this proposal reminds me of the fortune file entry, “Whenever you see a sign that says ‘no exit’, it means there is an exit there.”

Specifically, under this proposal, whenever you see a nonsubclassable, non-final class (which I suppose would in fact be any class not explicitly marked as subclassable), it would mean that the library implementor IS in fact subclassing it. Otherwise, it would just be final. Therefore, it’s by definition a perfectly reasonable class to specialize. The implementor just doesn’t want YOU doing it.

Maybe the implementor has a very good reason for this. But in the modal case, probably not. As the ladies on Jerry Springer say: you don’t know me; you don’t know my life. You really have no idea how I’ll be using your API or what I’ll be trying to achieve. In most cases, I'll have both your library source code and intimate knowledge of the application domain, so I’m probably in a better position than you to make these types of architectural assessments. You’re working with nothing but speculation, or even worse, your own myopic perspective of what your library is and how it ought be used. You think you know all about it because it’s Your Damn Library, but so very often, that conception turns out not to be not entirely accurate.

There’s a strong argument for allowing classes to be final, namely, static binding and performance. There’s a strong argument for allowing API to be nonpublic, namely, the ability to be clear about what’s included in the API and what’s not.

Beyond that, I really see no value in being able to schoolmarmishly forbid subclassing and overriding just out of conservatism, regardless of the syntax for this feature or the default behavior. If you want this, go write Ada code.

There should absolutely be a way to say “don’t subclass this.” But do you really need anything more than a comment that says “don’t subclass this?” Perhaps as a compromise, and as a concession to the value of automated checking, this feature could be reformulated as a warning system. A class marked as nonsubclassable could be extended only be including a corresponding acknowledgment keyword in the extending class, a kind of Swift version of -IHaveBeenWarnedThatAPFSIsPreReleaseAndThatIMayLoseData.

Either way, I would be sad to see nonextentability become the default behavior of Swift. That just doesn’t seem like it’s in anyone’s best interest.

Garth