In extension methods should work for enums

[mburbea]

I was writing an extension method and I discovered something odd.

Consider the following example:

public static class C
{
        public enum E { }
        public static E M(this in E e) => e;
}

This shows the following error:

Enums are concrete value types, so I feel this error is incorrect

[bernd5]

Indeed, it seems to be a missing implementation for by in-ref extensions methods for enums. It should be moved to roslyn, or?
I found nothing about enum-extensions in the readonly-ref proposal.
But under the hood they are just structs, too. Therefore it should work for them, too.

[333fred]

FWIW, while I don't necessarily have a problem with allowing this, there is overhead in passing a value by ref instead of by value, and you're likely to be better-served by just passing the enum by value. in is generally best-used for larger structs that would be expensive to pass by value, while an enum is going to fit into a single register on most modern platforms.

[tannergooding]

There are use cases for passing by ref yes, but when the value is not actually being mutated then it is less efficient and can actually hurt perf (especially when the method isn't inlined) because the JIT has to treat it as address taken.

[tannergooding]

For cases like Hardware Intrinsics, we actually explicitly changed many of the methods off being instance and onto being by value extension methods instead to overcome the issue of instance methods being passed as in (or ref for non-readonly structs).

Just compare what we expose on:
https://source.dot.net/#System.Private.CoreLib/Vector128.cs,39cf292fbdb3dfaf vs https://source.dot.net/#System.Private.CoreLib/Vector128_1.cs,a7d647b6968ad0f9

You'll see that the only instance methods we have are ones where C# exposes a fundamental limitation on making it an extension method.

[mburbea]

That's good insight, thank you. I still think it should be allowed even if it isn't particularly beneficial in the usual case.

[theunrepentantgeek]

Keep in mind @mburbea that language changes come at a very high cost - they need formal specifications, implementations, tests (lots of tests!) and ongoing maintenance.

A feature needs to be highly beneficial to be worth the effort - especially given the opportunity cost that other features can't be progressed while someone is working on this.

This is often referred to as Every feature starts with -100 points.

[mburbea]

@theunrepentantgeek, my understanding of this feature is that it's lack of implementation is an oversight. Not an intentional restriction. See both Fred's and Cyrus's comments earlier. Now I agree, it's not a particularly high priority. Outside of places where you want to mutate the ref, or do unsafe manipulations, its probably a performance downgrade unless you can be sure it'll inline.