Automatically seal not-derived internal and private classes

[TonyValenti]

I saw this:

dotnet/runtime@bdc8e42

And it made me think that, since the compiler knows if a class is derived, this is something the compiler could do automatically. Or at least offer a code fix for it.

[yaakov-h]

dotnet/runtime#49944 will offer a code fix for it, assuming the project goes ahead.

[DavidArno]

Interesting. I didn't realise there were performance benefits to sealing classes. I seal everything by default as (in my opinion; other opinions are available) it makes for more robust and reliable code as derived classes have to be planned and intended. I can now add the "and it increases the performance of the code" line to my argument arsenal now for seal-by-default. And as a bonus, an "official" analyzer for prompting me to remember to seal even public classes would be amazing. 😃

[YairHalberstadt]

As discussed in dotnet/runtime#49944 this can't be done automatically because types can be created at runtime via reflection.Emit

[AartBluestoke]

agreed, one my libraries generates types derived from a central type at runtime; i think if things with no children auto-sealed, my code would fail at least 4 different ways.

[theunrepentantgeek]

The compiler can't know enough to seal automatically; but the developer can - and it's an easy change.

[canton7]

See this discussion on why the JIT can't automatically seal types: dotnet/runtime#49944 . Many of those arguments also apply here.