sealed keyword for methods to block hidden overrwrites without new from happening

[Muchaszewski]

Problem

Currently when writing new methods with inherited class we are allowed to "overwrite" methods with the same signature as is.

abstract class Foo
{
    // Called by some API and we don't want to override it by accident
    public void Test()
    {
        TestToInherit();
    }

    public abstract void TestToInherit();
}

class Boo : Foo
{
    public override void TestToInherit()
    {
        // some work
    }
    
    public void Test()
    {
        // we hidden this method by "accident"
    }
}

Right now, this code will happily compile although will result in 2 warnings. CS0108 & CS0114.

The keyword 'new' is required on 'Test' because it hides method 'void Foo.Test()'

We can set those warnings as errors, but there might be moments where such behaviour would be wanted (without new keyword)

Idea

My idea here would be to add sealed keyword to any method in order to force new keyword when hiding base methods, or even outright block it from overwriting/hiding. There might be possible performance benefits to seal methods if compiler can for sure know that we cannot use new keyword in given context.

abstract class Foo
{
    // Called by some API and we don't want to override it by accident
    public sealed void Test()
    {
        TestToInherit();
    }

    public abstract void TestToInherit();
}

class Boo : Foo
{
    public override void TestToInherit()
    {
        // some work
    }
    
    public void Test()  <---- Compilation error, class method with the same signature is `sealed`
    public new void Test()  <---- Compilation error, class method with the same signature is `sealed` (optional)
}

Thoughts

Benefits of sealing methods like that would allow programmers to make conscious decisions on when they want to "lock" method signature from being overwriten/hidden.

I personally would use this in the following context. Having interface that requires method Test but I want to perform some actions before/after the final implementation of the method. So I would implement TestToInherit method that would be abstract and implemented in all children of the base class.

This would allow me to write consistent code and be conscious of all the implications that come with sealing a method. I am aware of sealed virtual but this doesn't prevent from accidental hiding in child class. Also not having to worry about overwriting virtual methods and remembering to call base methods.

This would also be beneficial to when we want to use Reflection to call those methods by name (for some reason). We can assure that this method is always one and true to the base class, and that child classes do not overwrite it's behaviour (accidental or on purpose).

[HaloFour]

IMO, you already have the mechanism to control this by making those warnings into errors. For a case where you want to allow hiding without new you can suppress the warning at that point in time, but IMO I don't know why you'd want to. Given that the two methods really have no relationship to each other, and are completely separate as far as the runtime is concerned, I don't think that adding a new language feature here makes sense.

[ufcpp]

dotnet_diagnostic.CS0108.severity = error

[huoyaoyuan]

<WarnAsError>$(WarnAsError);CS0108<WarnAsError>

[TahirAhmadov]

There might be possible performance benefits

I don't think so, because if the base class's non-virtual method is called, it doesn't make any difference whether any derived types exist which have new methods with the same signature - those calls to the base method are not affected whatsoever.

Benefits of sealing methods like that would allow programmers to make conscious decisions on when they want to "lock" method signature from being overwriten/hidden.

I hate to be that guy, but an analyzer would work great for this.

I personally would use this in the following context. Having interface that requires method Test but I want to perform some actions before/after the final implementation of the method. So I would implement TestToInherit method that would be abstract and implemented in all children of the base class.

This would allow me to write consistent code and be conscious of all the implications that come with sealing a method. I am aware of sealed virtual but this doesn't prevent from accidental hiding in child class. Also not having to worry about overwriting virtual methods and remembering to call base methods.

Are you worried that a child class's Test method will get called when you invoke the interface method? If so, that's incorrect - if the interface is implemented by the base class, the base Test method will be the one implementing the interface, and child classes don't affect that in any way. (Unless you make Test virtual and override it in a child class.)

This would also be beneficial to when we want to use Reflection to call those methods by name (for some reason). We can assure that this method is always one and true to the base class, and that child classes do not overwrite it's behaviour (accidental or on purpose).

If type is the child class type, then you can always use type.BaseType.GetMethod(...) to ensure that you get the base class's method.

[huoyaoyuan]

I personally would use this in the following context. Having interface that requires method Test but I want to perform some actions before/after the final implementation of the method. So I would implement TestToInherit method that would be abstract and implemented in all children of the base class.

This pattern is very common in BCL (Dispose() with Dispose(bool)).

I am aware of sealed virtual but this doesn't prevent from accidental hiding in child class.

Even with this proposal, it doesn't prevent accidental explicit implementation in child class. The method implementing an interface doesn't necessarily have the same name.