SIP: Make classes `sealed` by default

Prioritization issues aside, my opinion of the current proposal is that it’s probably currently too contentious to be pushed into the language in any short timescale. Clearly lots of people enjoy the ability to unilaterally “patch” classes they use via subclasses, even if only in narrow circumstances like tweaking misbehaving third-party libraries or injecting hooks into test code.

For myself personally, my work codebase does this a reasonable amount, even if we generally try to avoid it. Generally if we can’t “patch” things via inheritance, we’re forced to mangle source code and maintain patch files or branches, both of which are a huge pain. We generally don’t inherit/override concrete classes much in “normal” circumstances, so the fact that you can doesn’t really cause us any hardship or mess

What about if we were less ambitious: we only make case classes sealed/final by default, and we make the sealed modifier transitive to automatically apply to subclasses? That would fix one long-standing wart while also likely not cause any migration pain, since people generally treat case classes and sealed hierarchies as final anyway (even if they forget to seal everything as necessary to enforce that)

11 Likes