[Proposal] Static extension methods

[ashmind]

Problem

In modern C#, it is possible to add extension methods that imitate instance methods, but not static methods.

There are quite a few use cases for this:

1. Direct API extension for popular static classes
   Console, Assert, Path, etc.
   This can be worked around if library authors switch to statically imported instance properties instead of classes, but it is extremely unlikely to be the right design choice for BCL APIs.
2. Polyfilling future functionality
   At some point, TPL team was using TaskEx for future previews, since they couldn't extend Task -- complicating migration from preview to the real thing. And if someone wants to implement new Task.FromException in pre-4.6 .NET -- they are out of luck as well, unless they choose a different class name.

Design

Given the syntax currently used by instance methods, extending this to static doesn't feel straightforward.

One simple idea could be just to extend [ExtensionAttribute]:

[Extension(typeof(Task))]
public static Task FromException(Exception ex) { ... }

But please feel free to propose better designs. And I assume C# team did have some potential design for this in mind then choosing the instance syntax?

Pros

1. Allows extension of static APIs, which is currently awkward
2. Allows polyfilling of static APIs, which is currently impossible

Cons

1. I don't have a good syntax proposal (though I personally would be just as happy with an attribute)

Community

1. StackOverflow: Can I add extension methods to an existing static class? has 247 votes, 45 ⭐
2. UserVoice: C# support static extension methods like f# has 549 votes

[paulomorgado]

Leaving, for the moment, how would that be declared, can you show some examples of how would that be used and its benefit and how would the compiler translate it?

[SolalPirelli]

One possible syntax would be to copy F# type extensions: to extend a type, declare another type with the same full name (i.e. in the same namespace).

[Rekkonnect]

This really interferes with partial. That solution would mean that every declared member becomes partial and is open for extension of whatever form, and then partial becomes useless. It was initially designed so that it only opens up the explictly declared members for split declaration.

[ashmind]

@paulomorgado

Example translation:

using System.Threading.Tasks;
/*...*/ Task.FromException(ex) /*...*/

translates to

/*...*/ SomeThirdPartyNamespace.TaskPolyfill.FromException(ex) /*...*/

[ashmind]

@SolalPirelli I considered this -- could also be an extension of partial keyword to allow cross-assembly partials.

The problem is -- what happens with instance methods? If we allow them, it would introduce a totally different syntax for instance extension methods. If we block them, it becomes a bit weird/inconsistent.

[paulomorgado]

@ashmind

/.../ SomeThirdPartyNamespace.TaskPolyfill.FromException(ex) /.../

Where does this TaskPolyfill come from? What is it? An inner class or a property?

[paulomorgado]

@ashmind, as of now, the partial keyword identifies a partial type definition and not a partial type.

[ashmind]

@paulomorgado

Where does this TaskPolyfill come from? What is it? An inner class or a property?

A public static class in SomeThirdPartyNamespace.

as of now, the partial keyword identifies a partial type definition and not a partial type.

I know -- this could be extended though. But at the moment I'm not advocating for that -- just looking at syntax options.

[ilmax]

I really like the idea, and hope to get this feature!

The syntax is a tricky part, I personally don't like using an attribute to recognize static extension methods, what about this?
public static void WriteColoredLine(this static Console, string line, ConsoleColor color) {}

Essentially we add static after this and the static type we would like to extend.

I'm open to other syntax suggestion.

[ryno1234]

I like the idea, but I'd remove the this part of the argument since this isn't allowed in static methods on a static class. Instead just sticking with static makes sense to me.

public static void WriteColoredLine(static Console, string line, ConsoleColor color) {}

[HellBrick]

Would something like this be possible?
public static void Console.WriteColoredLine( string line, ConsoleColor color ) {}

Since the class that declares such a method will probably need to be static anyway, it's a safe bet that it won't be able to implement an interface, so no possible conflicts there. However, just in case this restriction may be lifted somewhere in the future or a better way to differentiate from an explicit interface method implementation is needed, it might be better to throw in an additional keyword into the mix:
public static extension void Console.WriteColoredLine( string line, ConsoleColor color ) {}

[paulomorgado]

I don't know if this is possible at the CLR level, but would it be enough if the compiler would not treat as ambiguous if the same fully qualified name of exists in more than one assembly?

I'm failing to see the benefit of:

Console.WriteColorodeLine(ConsoleColore.Balck, "test");

Over:

MyConsole.WriteColorodeLine(ConsoleColore.Balck, "test");

Specially now that we have static imports.

[chrisaut]

I think the main benefit is discoverability. It just "feels" better.

I really likes this proposal. As for syntax, I don't like the "this static Console" at all, this seems to make no sense at all other than it looking similar to existing extension methods:
-- "this" makes no sense in a static context
-- "static" is never used as a parameter modifier
-- "Console" is not the name of a variable, but it seems that way with this Syntax
-- we are not passing anything, so why would this whole thing be defined as a parameter?

I agree with @HellBrick :

public static class MyConsoleExtensions {
  public static void Console.WriteColoredLine(string line, ConsoleColor color) {} 
}

This feels the cleanest IMO, and the Type.Method syntax already has a precedence for explicit interface implementations (IInterface.Method) so it doesn't look all that out of place. Of course static extension methods, just like regular ones, need to be hosted inside a public static class.

I guess the compiler really just has to rewrite Console.WriteColoredLine method calls to MyConsoleExtensions.WriteColoredLine. It's probably mainly a question of intellisense discovering these?

[ashmind]

It is interesting to also consider the design in a wider context.

There is #112 for extension properties (no syntax yet?) and there might be static extension properties in the future. I can't say I'm a fan of Type.X declaration syntax above (maybe I'll just need to get used to it) -- but it is definitely well-suited to support static extension properties.

[MrJul]

👍

Alternative syntax:

public static Task FromException(Exception exception)
as Task.FromException
{ ... }

or

public static Task FromException(Exception exception)
in Task
{ ... }

[paulomorgado]

What do you propose for overload resolution?

[ashmind]

@paulomorgado Same rules as for instance extension methods (I don't remember all the details, but in practice it seems to work pretty well).

[ZacharyPatten]

I'm a big fan of this feature. There are already multiple examples in the chat, but just to add a few more...

📄 Console::FlushInputBuffer _[Expand]

Source Code:

public static void Console::FlushInputBuffer(bool intercept = true)
{
	while (Console.KeyAvailable)
	{
		Console.ReadKey(intercept);
	}
}

Usage Example:

Console.FlushInputBuffer();

📄 Console::PressToContinue _[Expand]

Source Code:

public static void Console::PressToContinue(ConsoleKey key = ConsoleKey.Enter)
{
	if (!key.IsDefined())
	{
		throw new ArgumentOutOfRangeException(nameof(key), key, $"{nameof(key)} is not a defined > value in the {nameof(ConsoleKey)} enum");
	}
	while (Console.ReadKey(true).Key != key)
	{
		continue;
	}
}

Usage Example:

Console.PressToContinue(ConsoleKey.F);

📄 Array::newFromRanges _[Expand]

Source Code:

public static int[] Array::newFromRanges(params Range[] ranges)
{
	int length = 0;
	foreach (var range in ranges)
	{
		if (range.Start.IsFromEnd) throw new ArgumentException(nameof(ranges));
		if (range.End.IsFromEnd) throw new ArgumentException(nameof(ranges));
		if (range.Start.Value < range.End.Value)
		{
			length += range.End.Value - range.Start.Value;
		}
		else
		{
			length += range.Start.Value - range.End.Value;
		}
	}
	int[] result = new int[length];
	int index = 0;
	foreach (var range in ranges)
	{
		if (range.Start.Value < range.End.Value)
		{
			for (int i = range.Start.Value; i < range.End.Value; i++)
			{
				result[index++] = i;
			}
		}
		else
		{
			for (int i = range.Start.Value; i > range.End.Value; i--)
			{
				result[index++] = i;
			}
		}
	}
	return result;
}

Usage Example:

int[] array = Array.newFromRanges(1000..990, 10..991, 9..0);

📄 BindingFlags::All _[Expand]

Source Code:

public static BindingFlags BindingFlags::All() =>
	BindingFlags.Public |
	BindingFlags.NonPublic |
	BindingFlags.Instance |
	BindingFlags.Static;

Usage Example:

using System;
using System.Reflection;

class Program
{
	static void Main()
	{
		foreach (var member in typeof(Program).GetMembers(BindingFlags.All()))
		{
			Console.WriteLine(member);
		}
	}
}

Note: this specific example would probably be better handled with a GetAllMembers extension method on Type, but there are other cases where a MyEnum.Subset() would help.

I have many more...

[ProIcons]

Yeah this would be very helpful in many situations, even extending BCL Types. For instance making a TimeSpan parser for ISO8601 format

[sgf]

I've had countless discussions, but very few have been achieved. I suggest that all friends give up participating in the discussion later, because your discussion will not receive any attention at all.

[333fred]

And I quite comfortable with the assertion that none of the other features you are considering, or have in your list of priorites, that you think are so important - have that trait.

This is simply not true. Just a few of the things that are top of mind from the C# feature list:

• [Proposal]: Static abstract members in interfaces #4436 - nothing even approaching possible today.
• [Proposal]: Improved Definite Assignment Analysis #4465 - solves a number of customer pain points that have been reported over the years.
• Proposal: Allow [AsyncMethodBuilder(...)] on methods #1407 - extremely useful for the BCL and other large-impact users to improve perf for large swaths of customers.
• [Proposal]: Enhanced #line directives #4747 - significantly improves the debugger experience for dsl customers, most notably razor users.
• Champion "Allow no-arg constructor and field initializers in struct declarations" #99 - technically possible in IL, but not possible in C# today.

[bazzilic]

The team isn't ignoring static extensions.

Yes, the team isn't ignoring it, for the last 6 years the team was laser focused on not adding this feature. In one of the smallest feedback channels, this feature request remained active for 6 years and collected hundreds of supportive comments, so the team is adamant that nobody needs this. Such features as and and or instead of && and || on the other hand...

[HaloFour]

@bazzilic

There are thousands of language proposals on this repository that fit that bill. Most will simply never be implemented because they will never bubble to the front of the backlog that easily extends for more than a decade, assuming that they have interest from the language team at all.

Something like this proposal has been a part of a much larger design discussion which is seeking to add a much wider range of capabilities to the language. That process takes time, as language design does, and there is no chance that this feature will be added separately beforehand given how likely the syntax would end up superseded and deprecated.

Such features as and and or instead of && and || on the other hand...

Pattern matching is simply a higher priority feature, and has been an ongoing project since longer than Roslyn has been on Github. Those keywords are not synonyms for the existing Boolean operators and they cannot be used interchangeably.

[CyrusNajmabadi]

Yes, the team isn't ignoring it, for the last 6 years the team was laser focused on not adding this feature.

Yes. It's not as important as the other things we worked on to us.

Such features as and and or instead of && and || on the other hand...

Yes. Patterns are much more important than this. Given all this time and everything we've learned, i would make the same decisions. And that applies to the future as well. I would not champion this feature and would instead prefer our efforts be spent on other language proposals.

[CyrusNajmabadi]

And I quite comfortable with the assertion that none of the other features you are considering, or have in your list of priorites, that you think are so important - have that trait.

I don't see how this is relevant. We're not going to prioritize this item because of that (ignoring that it isn't even true). We're going to prioritize based on how important we think the feature is to the ecosystem. And, frankly, while i only speak for myself on this, this item barely meets any of my criteria for consideration.

[Korporal]

[HaloFour]

"Partial" doesn't exist in the CLR. It's purely a syntax trick, the compiler takes all of the "partial" declarations and merges them into a single one that is emitted into the assembly.

[CyrusNajmabadi]

It's purely a syntax trick

Extension methods too :)

[miegir]

I asked the same quiestion a long time ago and the answer was that there will be problems when in two static classes would be methods with the same signature. F# doesn't have this problem because in F# the order (of opens in this case) matter and the last opened class wins. In C# there are no ordering rules. And, in order to resolve conflicts, there should e a way for some static classes to be marked as 'primary' (for example, the System's Console), while other classes be marked as 'extension' classes.

[Korporal]

I wonder if one could change the CLR so that all static classes get treated as if they were declared explicitly as "partial"? Would this be a breaking change? If it isn't a breaking change then the problem is solved. One could just declare their own Console (by way of example) static class that would become part of the existing Console class and we're good...

namespace System
{
     public static class Console
     {
         public static void WriteGreen(string str) => ...
     }
}

[YairHalberstadt]

My reccomendation would be for the compiler to allow referencing a static method of a type when there's multiple types with the same name in scope, and just do ordinary method resolution on the method (#1988).

So for example, you would define your own type `

namespace MyRootNamespace
{
     public static class Console
     {
         public static void WriteGreen(string str) => ...
     }
}

Then when you were in a file, you could use both the methods on MyRootNamespace.Console and Sytem.Console:

using MyRootNamespace
using System

Console.WriteLine("This is ordinary text"); // Uses System.Console
Console.WriteInGreen("This is green text"); // Uses MyRootNamespace.Console

The advantage of this approach is it doesn't require adding a new top level concept to C#, but acts pretty much the same way static extension methods would - if you import the right namespace, you magically see more methods on the Console class. And all for the cost of loosening a restriction on method resolution.

[HaloFour]

Also has the advantage that it can't break any code given that currently trying to reference that type would result in:

error CS0104: 'C' is an ambiguous reference between 'A.C' and 'B.C'

Unless I'm missing a weird edge case this would only enable code that is illegal today.

[TahirAhmadov]

Also has the advantage that it can't break any code given that currently trying to reference that type would result in:

One can make the argument that changing code that used to be illegal to become legal is somewhat of a breaking change. Developers rely on type conflict rules as they are today. Blurring that line can introduce bugs going forward. In practice, I don't think it's a huge issue; but (a variation of) the traditional extension method syntax is probably better, anyway.

[CyrusNajmabadi]

One can make the argument that changing code that used to be illegal to become legal is somewhat of a breaking change.

Not really. Users making mistakes isn't a break. A breaking change is when existing code either no longer runs, or runs with different meaning (and there are categories for that happening with or without a recompile happening).

Users making more mistakes doesn't fall into that. That's just more an argument around if this comes with undesirable negatives that would be problematic.

[TahirAhmadov]

@YairHalberstadt 's proposal is about the only one i think i'd contemplate taking. It's lightweight, doesn't need runtime changes,

None of these proposals for the syntax entail run time changes, do they? The existing ExtensionAttribute can be re-purposed by decorating the method with it, instead of the first argument.

and basically just affects how lookup/resolution applies.

And this is a much bigger change than introducing a new combination of keywords to solve one specific need. Now something very core to the language is modified.

[TahirAhmadov]

Not really. Users making mistakes isn't a break.

I agree, technically currently running code doesn't break, but a very fundamental C# quality is changed. Yes we can't stop users from making mistakes, but we can avoid making it easier to do so.

The other problem with this is that currently instance extension methods have a certain overload resolution rule; we know it's an extension method and can place it in the hierarchy accordingly. On the other hand, with this "another class with the same name" proposal, we don't really know which one was meant to be the "original" class and which one is "extensions". So, if you have System.Console.WriteLine and MyNS.Console.WriteLine, how does the compiler decide which one to call? Especially if MyNS is another referenced DLL?

Also I shared @ZacharyPatten 's concerns around generics. The current extension syntax deals with all the generic permutations perfectly. Whereas the "another class with the same name" proposal cannot.

[darrenoakey]

4436 I admit is very cool and in my mind addresses exactly the same problem static extension methods do ie - allows developers who know what they are doing to make life easier for developers who don't. 4465 doesn't really give you anything that you can't just do with different syntax - 1407, 99, 4747 can be done with a weaver today.

…

On Fri, Aug 6, 2021 at 2:54 AM Fred Silberberg ***@***.***> wrote: And I quite comfortable with the assertion that none of the other features you are considering, or have in your list of priorites, that you think are so important - have that trait. This is simply not true. Just a few of the things that are top of mind from the C# feature list <https://github.com/dotnet/roslyn/blob/main/docs/Language%20Feature%20Status.md> : - #4436 <#4436> - nothing even approaching possible today. - #4465 <#4465> - solves a number of customer pain points that have been reported over the years. - #1407 <#1407> - extremely useful for the BCL and other large-impact users to improve perf for large swaths of customers. - #4747 <#4747> - significantly improves the debugger experience for dsl customers, most notably razor users. - #99 <#99> - technically possible in IL, but not possible in C# today. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2505 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYTIZ3WWB7LHS67XDJU46DT3K64JANCNFSM4YGDQJOA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[deeprobin]

Yes static extension methods are things I would like to have in C#

[TahirAhmadov]

How about this?

public static class ConsoleExtensions
{
  public static void WriteColoredLine(static Console, string line, ConsoleColor color) {}
}

Basically drop the this altogether, replace with static keyword, and obviously no need for the actual local parameter. This is consistent with instance extension methods, yet different enough to tell the difference.

[0x0737]

Why try to extend the syntax that will become outdated soon? Doesn't #1711 include this and even more with a better syntax?

[Rekkonnect]

This design admits a slight flaw in the current design of extensions. The definition of extension methods must be within some static class.

This is not a great design by itself since there's nothing that guarantees that the target class is designed to only contain extension methods for some other class. Most static classes that contain extension methods specialize in providing such methods for one specific type. In this instance, the same would apply for static classes for which extension methods are created.

Instead of following that same old principle and adding some weird syntax to extend it, there could be some element that more represents the definition of a container type (maybe drop the type concept altogether) that defines extension methods for some specific class.

A design that would meet the above criteria would be something like

// Definition:
public extension class ConsoleExtensions : Console
{
    public static void WriteColoredLine(string line, ConsoleColor color) { }
}

// Access:
using <namespace of ConsoleExtensions>
Console.WriteColoredLine("line", ConsoleColor.Green);

[TahirAhmadov]

Why try to extend the syntax that will become outdated soon? Doesn't #1711 include this and even more with a better syntax?

Good point, if that issue is on track to be implemented, and the extension class part of it will support static methods, then there is definitely no need to add this "static extension methods" feature.

[Eli-Black-Work]

Gotta say, I'm loving this syntax! 🙂

[jimmyfluorite]

my reccomendation, use discards (_), as we would declear the class type to be extended, and we would never use a instance.

public static class MyExtensions
{
    public static string Add(this string _, string a, string b)
    {
        return a+b;
    }
}

one more, could we also use extend operators like this?

public static class MyExtensions
{
    public static string operator + (this string _, string a, string b)
    {
        return a+b;
    }
}

[HaloFour]

That code already means that it's a static extension method that accepts the first parameter that happens to have the name _, which has been a legal parameter name since C# 1.0. The _ identifier does not (and cannot) mean "discard" in that situation, nor can it be reinterpreted as such without changing the existing meaning of the code in breaking ways.

[jimmyfluorite]

i am not sure if "out _" was a legal param name before it started to mean discard at C# 7.0. if so, that means the meaning of _ "could be changed and had been changed".
if so, i suggest that we could change the meaning of _ here again.

[333fred]

_ is still a valid parameter or local name in C# today. That's why the following code (which had meaning prior to C# 7.0) does not compile today:

int _;
M(out _); // error CS1503: Argument 1: cannot convert from 'out int' to 'out string'

void M(out string s) => s = null;

[jimmyfluorite]

yes, that is exactly what i mean.
_ was only a regular parameter or local name prior to 7.0, but since then it had been changed to mean discard, in some case.
do you mind to change _ again to make it mean "static extend method"?

public static class MyExtensions
{
    public static string Add(this string _, string a, string b)
    {
        return a+b;
    }
}

to declare a static method, we need to pick a class name, but not an instance name.
in this case, this string _ means we extend a method for string class, but we don't need the instance name, so it will be a static extend method.
i couldn't say i know very much about the compiler, and it depends on your choice, but i don't find any problem on the grammar level.

[HaloFour]

@jimmyfluorite

_ was only a regular parameter or local name prior to 7.0, but since then it had been changed to mean discard.

The meaning of _ has not changed in any context where _ already had a meaning, such as the names of parameters.

[acaly]

Static extension methods is also useful for compatibility in multi-targeting projects. New frameworks introduce some new API as static methods (e.g. in Math). For non-static methods (including extension methods), we can add our own (possibly slower) implementations as extension methods in the project, but for such static methods, we cannot add implementation without this static extension method in the language.

[HaloFour]

You can already do this with preprocessor directives, especially since you'd have to recompile the project anyway in order for the compiler to target the framework method instead of your own extension method. That approach might be a little bit more verbose but it's also more explicit and avoids the resolution issues that can arise with extension methods, specifically that the extensions members can only be considered when all candidate members on the type have been eliminated.

[acaly]

@HaloFour How can I do this for static methods?

[HaloFour]

@acaly

How can I do this for static methods?

Preprocessors can include/exclude arbitrary blocks of code, even within a method.

#if NET7_0_OR_GREATER
    double result = Math.SomeNewMethod(x, y, z);
#else
    double result = MyMathImpl.SomeMethod(z, y, z);
#endif

Although to make it simpler I might delegate all of those operations to a helper class so that I only have to worry about the preprocessor being used in one place.

internal static class MyMathImpl {
    internal static double SomeMethod(double x, double y, double z) {
#if NET7_0_OR_GREATER
        return Math.SomeNewMethod(x, y, z);
#else
        // our own implementation here
#endif
    }
}

A bunch of those preprocessor symbols are provided by default based on the target framework or you can #define your own.

See: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives#conditional-compilation

[acaly]

I know preprocessor directives, but it significantly increase the effect to use new APIs. Consider I use one API method 10 times in one of my methods, how would that method look like if I use #if?

I can afford adding a few source files so that most source files do not contain any preprocessor directives. A helper class might be better, but it is still harder to use than static extensions.

[HaloFour]

@acaly

Consider I use one API method 10 times in one of my methods, how would that method look like if I use #if?

If you followed by second suggestion and used a helper class to dispatch conditionally then it would look like 10 normal method calls.

[SoftCircuits]

Looks like this one has been here for a while now. FWIW, here's how I would like to use it.

Let's say I want to write a static method called Format() that adds additional parameters and functionality to string.Format().

How would I make it easily discoverable? I could call my class StringHelper or something, but C# developers don't know this class, and are already familiar with string. It would be nice if I could add my static method to the list of string.Format() overloads.

I don't see any way to do this now.

[theunrepentantgeek]

Aside from the decidedly non-trivial implementation issues (overload resolution is already incredibly complex), I believe the existing limitation was very deliberate - wanting to avoid surprising results.

In the benign case, importing (or updating!) a NuGet package might result in a different overload of Format being called, changing output in unexpected ways.

In the non-benign case, an attacker, having compromised a popular NuGet package, could insert themselves into the code path for Format, silently scanning for credit card numbers and siphoning them off.

[SoftCircuits]

I don't know why any of those objections wouldn't apply to regular extension methods.

[TahirAhmadov]

@theunrepentantgeek , like @SoftCircuits wrote, all the same considerations apply to regular extension methods. You want to make sure you trust 3rd party libraries you use; and C# prefers a compatible native method over an extension, so there is nothing new with extension static methods (instance/static properties & events, too, when #5497 is ready).

[MadL1me]

Can someone from the community just make PR for this, without lots of involvement from dotnet team? Or it would be rejected without question, if its not a "champion" and "milestone"? This feature is requested and wanted for already around 8 years, and still active and discussed. I would love to do PR myself, if it would be reviewed, because it is feature I'm personally waiting for 3-4 years

[HaloFour]

Can someone from the community just make PR for this, without lots of involvement from dotnet team? Or it would be rejected without question, if its not a "champion" and "milestone"? This feature is requested and wanted for already around 8 years, and still active and discussed. I would love to do PR myself, if it would be reviewed, because it is feature I'm personally waiting for 3-4 years

Language design proposals must be accepted by the team before any contribution may be considered, community or otherwise.

The language team is interested in this space but they are exploring it as a part of the larger "extension everything" and "roles" proposals. It's very likely that such proposals will end up with a different syntax than is suggested here so I don't think any proposal which only addresses static methods is likely to be considered.

[333fred]

Or it would be rejected without question

Correct. As detailed in the Roslyn contribution guide: https://github.com/dotnet/roslyn/blob/main/CONTRIBUTING.md#submitting-pull-requests

[CyrusNajmabadi]

without lots of involvement from dotnet team?

The problem with doing things that way is that features will likely not at all work well together. And there will very likely be clashes with the work we are doing (like with Roles and Extensions). 'Extensions', in particular, subsumes this proposal. So we have two new ways to do the same thing. One of which we would then likely have to dissuade people from using.

[yuyang9119]

There were some good ideas earlier, but some didn't consider generics, and some directly placed the type in the parameters. I believe that, in any case, extension methods should allow non-extension style invocation. Anyway, here are my thoughts:

struct S
{
    public static int F1() => 42;
    public static void F2(int arg) { }
}

interface I
{
    abstract static int F1();
    abstract static void F2(int arg);
}

class C : I
{
    public static int F1() => 42;
    public static void F2(int arg) { }
}

static class Ex
{
    public static void F1F2<this T>() where T : S => S.F2(S.F1());
    public static void F1F2<this T>() where T : I => T.F2(T.F1());
}

static void Main()
{
    S.F1F2();
    C.F1F2();
    Ex.F1F2<S>();
    Ex.F1F2<C>();
}

I think this is the most compatible with existing syntax and supports generics. This requires supporting value types as generic constraints (currently, it only accepts the type itself as a type argument). For reference types, I think static extension methods should be allowed to be called through derived types, there's no harm in that, but it's okay if it's not allowed.

------------------ [EDIT] -------------------
Inspired by @Rekkonnect, I feel that this might be better:

static class Ex
{
    public static void F1F2() for S => S.F2(S.F1());
    public static void F1F2<T>() for T where T : I => T.F2(T.F1());
}

static void Main()
{
    S.F1F2();
    C.F1F2();
    Ex.F1F2();
    Ex.F1F2<C>();
}

[Rekkonnect]

I'm very hesitant of the this T syntax for these. While following a pattern based on the current way extension methods are declared, it's the existing syntax that is somewhat problematic. It's also the main reason why enabling extension properties and accessors isn't that easy; they'd require additional special syntax.

I would completely drift away from this and follow a pattern similar to what roles and extensions are going for, which is declaring the entire class as a dedicated one for extensions for a specific type.

If you wish to encapsulate multiple types in the same extension class, you'd then have to wrap the extensions into a type extension block for each type accordingly.

Examples for the above are:

// A classic extension type based on the active proposal
extension SExtensions for S
{
    public static void F1F2() => S.F2(S.F1());
}

// Unknown about its support currently
extension IExtensions<T> for T
    where T : I
{
    public static void F1F2() => T.F2(T.F1());
}

// Not an active proposal
extension class F1F2Extensions
{
    for S
    {
        // Extension as the above
    }

    for <T>
        where T : I
    {
        // Extension as the above
    }
}

Note: in your example you have two F1F2 methods that have identical signatures only differing in the type constraints. Additionally, your constraint includes a direct struct type, which doesn't have any reason to be a generic method, and would also be an error.

[yuyang9119]

It seems to be two different approaches, one based on functional extension, and the other based on type extension. Perhaps both can be available, allowing programmers to choose the most suitable approach according to the situation.

[tw0po1nt]

Looks like it has been about a year since there has been any activity on this thread. I would love for this proposal to gain momentum again, as this would be a very useful feature to have. My 2 cents 😄

[TahirAhmadov]

#5496
#8696
#8843
#8943
#8917
#8916

[jnm2]

It's also on the schedule for tomorrow! https://github.com/dotnet/csharplang/tree/main/meetings/2025#wed-jan-22-2025