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

[Joseph Lord]

+1 I'm sold by Brent's reasoning that sealed is the only way to keep options open, both for any given library and for the whole Swift language. I've stayed quiet until now because while philosophically inclined to final by default I was concerned about potential complexity and confusion.

I haven't read everything on the mailing list but I've read several blog posts on both sides.

In terms of the necessity of subclassing it feels to me that subclassing where not designed for it is a similar in principle to using private APIs which may at times be the only way to achieve certain things but at least on iOS the App Store policies prevent that.

I don't have very strong views about the syntax I'm afraid but if this is something that could be reversed there should be an explicit version of the default sealed case (like internal is with for access controls).

Joseph

On Jul 19, 2016, at 8:43 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:

>> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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.
> 
> You know, one thing I haven't seen mentioned is that, just as sealed-by-default preserves the options of library programmers, it also preserves the options of the language itself.
> 
> Suppose the people who think this is a huge mistake are correct, and we ultimately conclude that sealed-by-default is a disaster. What can we do about it? Well, we change Swift 3+n to open all classes by default. This would be source- and binary-compatible with all existing code; the only wrinkle is that classes compiled with a sealed-by-default compiler would still be sealed. (And that's not even a problem yet, since stable ABIs are not a thing yet.)
> 
> The reverse, however, is *not* true. Going from open-by-default to sealed-by-default is source- and binary-incompatible. If we don't do it now, we may never be able to do it.
> 
> That means this is our one chance to try this. The outcome is uncertain; there are good arguments that it will improve things, but there are also good arguments that it will make things worse. But if we're afraid to try this now, we'll never be able to try it again, and we won't know if it would have worked. Whereas if we *do* try it now, we can always roll it back later.
> 
> Software quality is one of the biggest problems our profession faces. We handle crushing amounts of complexity, teetering towers of abstraction, intertwined code that's at the ragged edge of our ability to comprehend it. Quite possibly the most urgent need in our industry is tools to help us manage it.
> 
> Sealed-by-default might turn out to be a powerful tool for managing complexity, helping us prevent unexpected interactions between the implementation details of separate modules. Or it might not. But we ought to find out. If we always take the conservative option, if we always stick to the tried and true, we will never advance the state of the art, never find solutions to the problems that make "all software sucks" a truism.
> 
> We need to be bold and take a chance. If it doesn't work out, we can undo it. But if it does work out, we'll be better for it.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution