Readability of methods with explicit 'this' parameter

[risc26z]

For various technical reasons (mostly performance), I have a number of static methods with a parameter that is effectively a 'this' reference. Hence, these methods are littered with references to this parameter:

public class MyClass {
public static void DoSomething(MyClass obj) {
if (obj.X == obj.Y) {
obj.DoEqual();
} else {
obj.DoNotEqual();
}
}
}

Many such methods are more complicated. The sheer number of references to 'obj' (or whatever) make the code more difficult to read and understand than it needs to be. What would make the code much cleaner and more readable is if I could write:

public class MyClass {
public static void DoSomething(using this = MyClass obj) {
if (X == Y) {
DoEqual();
} else {
DoNotEqual();
}
}
}

Functionally, the two methods are identical. It's just that the latter contains a scope resolution hint to the compiler, making the programmer's life easier. (The "using this" syntax is, of course, just a suggestion.)

It also occurs to me that, if it were feasible to allow it, extension methods might also benefit from the same feature.

[TahirAhmadov]

Do you have any evidence to prove that using a non-virtual instance method is any slower than a static method with this passed in as the first argument? To my knowledge, both are invoked and inlined etc. exactly the same way.

[huoyaoyuan]

A null check will be performed in prior, I think. Though it will often be eliminated.

[risc26z]

I wouldn't expect much difference in terms of hard-coded calls. The benefit of static methods is that you can obtain, store, and use a function pointer, which is much kinder to the caches than a delegate. As far as I'm aware, there's no way to get a function pointer to an instance method.

[MillKaDe]

If MyClass is sealed, the Jitter might be tempted to devirtualize the call of the instance function DoSomethingInstance.

For function pointer, use a static wrapper function DoSomethingStatic.

code @ SharpLab

using System;
using static System.Console;

public sealed class MyClass {
  int X, Y;
  public MyClass (int x, int y) { X = x; Y = y; }  
  void DoEqual () { WriteLine (nameof (DoEqual)); }  
  void DoNotEqual () { WriteLine (nameof (DoNotEqual)); }  
  public static void DoSomethingStatic (MyClass obj) => obj.DoSomethingInstance ();
  public void DoSomethingInstance () {
    if (X == Y) {
      DoEqual();
    } else {
      DoNotEqual();
    }
  }
}

public static class Program {
  unsafe public static void Main () {
    Action<MyClass> FuncDel = MyClass.DoSomethingStatic;
    delegate*<MyClass,void> FuncPtr = &MyClass.DoSomethingStatic;  
    MyClass mc = new MyClass (1, 2);
    FuncDel (mc);  
    FuncPtr (mc);  
    MyClass.DoSomethingStatic (mc);
    mc.DoSomethingInstance ();
  }
}

[risc26z]

The wrapper is fine if DoSomethingInstance() is inlined, but there's no way to guarantee that. This is performance-sensitive code: I'm not going to change it in a way that makes it slower.

[HaloFour]

It also occurs to me that, if it were feasible to allow it, extension methods might also benefit from the same feature.

This will probably not be necessary with the new proposals for extensions which are written like instance members.