> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution > <swift-evolution@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
