> > We can introduce them as sealed interface (note: interface not type)
This is a new claim. Why is it that abstract classes can’t be sealed as well? (There is less _need_ for this, as abstract classes can use access control on their constructors to simulate sealing, but that’s a weak approximation, and doesn’t move us towards sums at all. > So either we go with an interface and in that can i think we should support > all ways to implement an interface or we go with a sum class and in that case > i agree that we do not need to support anonymous classes. I think what you’re really saying is: the syntax we pick will put ideas in people’s heads, and we should be wary if the most likely ideas it plants are not the ones we have in mind. Yes, that’s true. But it doesn’t remotely rise to the level of “forced move” that you seem to be implying. So rather than pounding the table and saying “it has to be this way”, can we try to frame the issue more as a mismatch between the candidate syntax and what we expect the user model to be, and work it from that direction? I don’t think I have to say it out loud, but just to be sure: the syntax should not drive the model, it should go the other way. If the syntax we’ve chosen is a poor fit for the model, first let’s talk about changing the syntax.
