The 'non-sealed' keyword looks not very java-ish.
There was a method to this madness. The goal is to *make* it Java-ish, by adopting this convention uniformly whenever we need the opposite of something. So when we need non-static, non-final, non-abstract, etc, these are ready and waiting for us, and each reinforces the others. It is the first one that bears the slings and arrows.
Consider the opposite of `final`, which we went through a bikeshed-paint on, but in the end didn't need immediately. The "obvious" opposite of final for a field might be "mutable", but that's a terrible modifier for a class or methods. Similarly, an opposite of final for classes or methods might be "open". But you see how this leads to an irregular taxonomy, where the opposite of X isn't even consistent across places where X can be used. This is actually what led us to the non- prefix, even though sealed was the first place to get it.
You could also think of this as a meta-bikeshed-budget-management move; without it, every keyword needs its own bikeshed to determine its opposite. And, knowing the community, every choice we make ("mutable") will have a half-life of complaints over something ultra-trivial -- only to be repeated on the next one. By picking a scheme that can be applied consistently, we avoid all that.
So while "open" may be locally better (and I don't disagree), I think it is globally worse.
As a minor note, `open` means something already in the context of a module descriptor -- "open to deep reflection". (ANd in fact, we can imagine that we may very well need this concept in the language.)
It adds cognitive load, especially to non-native speakers, as it includes the negation inside. Also, it complicates tooling implementation (in particular, lexing Java programs). Probably some of us want to move forward the hyphenated keywords proposal and need a guinea pig to experiment with, but this doesn't seem enough reason to justify its use. I suggest using the 'open' contextual keyword instead. The 'open' class/interface means that it can be inherited without any restriction. 'open', 'sealed', and 'final' keywords are mutually exclusive. Any class/interface is either 'open', or 'sealed', or 'final', no other option. The classes that don't directly extend/implement sealed classes/interfaces are implicitly 'open' (though it's possible to redundantly specify the 'open' keyword). The classes that extend/implement sealed class/interface must specify open/sealed/final explicitly. What do you think? With best regards, Tagir Valeev.
