In the interest of defining a clear, conservative space where sealed classes and interfaces can be used, which we may want to refine in future iterations, here's what it sounds like we want.
For each of local classes, anonymous classes, and member classes declared within one of these (plus, eventually, local interfaces and member interfaces declared within one of these): - It is a compile-time error to be declared 'sealed' - It is a compile-time error to extend/implement a sealed class or interface This limits the sealing features to top-level classes/interfaces and member classes/interfaces that can be named from the top level. Before we finalize the feature (after one or two rounds of preview), we should consider whether it makes sense to relax these constraints to allow any of: - Groups of member classes nested inside a local class - Groups of local classes that, via a new feature, support mutual recursion (don't know what the feature looks like, but we know it's something we want to explore) - Classes (including local/anonymous) that extend a sealed class but aren't in scope/nameable at the superclass's declaration
