[FR] Access static methods through instance symbols

[munael]

Design

class Foo {
	public static bool Bar(string x) => x == "x";
}

// [1]
// We can do:
var b = Foo.Bar("x");

// [2]
// I propose we should also be able to do:
var foo = new Foo();
var b = foo.Bar("x");

Example

Python's classmethod decorator leaves the method name accessible through instances.

Rationale

By allowing [2], the choice of making a method static becomes lighter syntax wise, while preserving the semantics.

static then becomes an annotation offering a part of some kinds of function purity.

The parts I have in mind are:

1. Function cannot mutate objects accessed from the surrounding scope (not arguments).
2. Function cannot mutate arguments passed to it.
3. Function sees data only through arguments passed to it. (No surrounding scope.)

This proposal provides (3.) by making switching a function between either kind seamless on the side of the caller in most cases. Until the caller explicitly needs to use the function in a context with no instance pointer. But until then, the syntax is the same.

This is important because otherwise making an instance method into a static function currently requires far-reaching, needless edits to switch the syntax. Even though from the callers' side, the interface may have remained the same. The internals of the function changing from requiring instance access to not requiring it should not be a breaking change.

[CyrusNajmabadi]

. The internals of the function changing from requiring instance access to not requiring it should not be a breaking change.

It is a breaking change though. Existing binaries will break now that the function is static instead of an instance method.

[munael]

Right. That's true of any signature changes though (here removing this).

But I'm more interested in the source side of things :T

[333fred]

Well, this is also a source breaking change, as new methods would be considered in overload resolution, potentially choosing these new methods instead of existing ones.

[munael]

Currently methods with the same signature that differ only in their static annotation conflict at definition time.

If we're talking about best-fit overload resolution, then yes.

But for consumers of the static function (previously an instance method) nothing changes.

For consumers of static functions... This's an API design question. If a method suddenly makes sense to be made a static function, that's what it should be. Ideally, the naming and the overall design would mean that the newly minted static function is indeed a better fit wherever the type system decides it is a better fit.

[canton7]

Currently methods with the same signature that differ only in their static annotation conflict at definition time.

I think the point is rather:

public class Foo
{
    public void Bar(object o) { }
    public static void Bar(int i) { }
}

new Foo().Bar(3);

Currently this picks the instance object overload. If static methods were also considered, this would pick the static int overload. Merely introducing this change could break existing code.

SharpLab

[333fred]

That's exactly it canton7.

[CyrusNajmabadi]

But I'm more interested in the source side of things :T

From the source side, I would want things to break. After all, why do I now have/need an instance that I'm calling the method off of when the method is static? I would want that all to break so I could remove all those instances.

[Flutterish]

This makes you forget whose responsibility Bar is. To me it speaks "foo does Bar", not "( Type ) Foo does Bar".
This also braks some semantics, like

class Expression {
    static Expression FromText ( string source ) { ... }
}

var myExpr = new Expression();
myExpr.FromText( "24 + 8" );

This just looks wrong. And it makes you think myExpr will assign some value to itself.