Why are C# classes unsealed by default, when their methods are non-virtual by default? [closed]

Question

Methods in C# are non-virtual by default. This answer to another question explains the advantage of doing it this way:

Classes should be designed for inheritance to be able to take advantage of it. Having methods virtual by default means that every function in the class can be plugged out and replaced by another, which is not really a good thing.

Even Anders Hejlsberg seems to give the same reason:

When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant. [...] You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises.

I agree with this reasoning: Usually when I create a non-private method, I just want to create code that can be called from somewhere outside the class. Usually, no thought is given to how somebody else might override this method and which effect that would have. For the special cases, I can use virtual to signal that did create the code in a way where overriding makes sense.

However, classes still unsealed by default. The default assumes that I spend the extra effort of making sure that inheriting a class makes sense.

Is there anything that makes a class different from a method in this regard?

---

EDIT
I don't really know what to change about the on hold - opinion based thing. I never asked for opinions. Maybe I have to say it explicitly?

I don't want opinions.

A correct answer would either provide an example of a class being different from a method, or state that there is no difference in this context.

Answer 1

I believe the question is "given that there are good reasons why methods should be non-virtual by default, why are classes not also sealed by default?"

One could also add: C# makes the default accessibility either internal, for top-level types, or private, for members of types; that is, it chooses the more restrictive and safer option; if a developer wishes a less restrictive, more dangerous option they can opt into it. Sealing by default would also be choosing the more restrictive and safer option as the default.

Also: unsealing a class is never a breaking change, but deciding later that you wish you'd made a class sealed and sealing it is a breaking change. C# typically prefers the design choice that encourages fewer breaking changes, so for this reason also, you would think that C# classes should be sealed by default.

We've identified three reasons why sealed by default is both a good idea and consistent with other design choices in C#. Why then is C# inconsistent in this regard, choosing to make unsealed classes the default?

I don't know. It's always struck me as a minor design flaw in C#. I've never seen a cogent argument for this choice, and I do not know if it was debated in early design meetings or not; that was before my time on the design team.

Unless you run into someone who was in that design meeting in 2001 and ask them, you might not get a satisfactory answer to your question.

I am in the habit of sealing every class I write unless I have a reason to design it for inheritance; I encourage everyone to do the same.