[Discussion]: Extensions

[333fred]

Discussed in #5496

^{Originally posted by MadsTorgersen November 30, 2021}
https://github.com/dotnet/csharplang/blob/main/proposals/extensions.md

[hez2010]

I prefer using of or something else to distinguish the type being extended and interfaces:

public extension Foo of int : IA, IB, IC, ...
{
    ...
}

Otherwise it will be too confusing if you are extending an interface:

public extension Foo : IA, IB, IC { }

vs

public extension Foo of IA : IB, IC { }

of can be relatively safely made as a keyword since it's neither a verb nor a noun, so almost nobody would choose of as an identifier.

[HaloFour]

I'm curious as to how the team weighs the relative benefits between "roles" and "extension implementation". It feels that without some additional effort in the runtime the two are somewhat incompatible with each other, so if those differences can't be reconciled which of the features might the team lean towards?

Personally, I find extension implementation much more exciting than roles, but that's just my opinion.

[FaustVX]

@hez2010
Maybe, instead of of, for would be a better name for the keyword as it's already a keyword.

public extension Foo for IA : IB, IC { }

[333fred]

I'm curious as to how the team weighs the relative benefits between "roles" and "extension implementation". It feels that without some additional effort in the runtime the two are somewhat incompatible with each other, so if those differences can't be reconciled which of the features might the team lean towards?

Who gave you an early preview of my notes? They're up now, discussion at #5500.

[sab39]

Here's a scenario that will be great fun to try to accommodate in the design:

interface IFoo { }
interface IBar { }
class Thing { }
public extension FooThing for Thing : IFoo { }
public extension BarThing for Thing : IBar { }
void Frob<T>(T t) where T : IFoo, IBar { }

Frob(new Thing());

On an unrelated bikeshedding note, what about using the existing reserved keywords explicit and implicit as modifiers, rather than treating roles and extensions as completely separate things? An extension is, more or less, just a role that gets applied implicitly based on type rather than needing to be explicitly named in the declaration. Using implicit role as the syntax would spell that correspondence out more (no pun intended) explicitly?

[CyrusNajmabadi]

@sab39 Given, as you've mentioned, how similar these two concepts are. I too am looking for a good syntactic way to convey that similarity, with a clear way to do indicate in which way they differ. Thanks for the explicit/implicit idea, definitely something we'll consider!

[TahirAhmadov]

I'm not sure if I should re-post my comments from the discussion here?
In short, I think the extensions and especially interface "adapters" make sense, but roles don't. The main motivation example - DataObject - is an anti-pattern, IMO; it runs into expensive runtime changes; and causes confusion - now you have to keep in mind when looking at an identifier in a "type receiving context" if it's a type or a role.

Here's a scenario that will be great fun to try to accommodate in the design:

interface IFoo { }
interface IBar { }
class Thing { }
public extension FooThing for Thing : IFoo { }
public extension BarThing for Thing : IBar { }
void Frob<T>(T t) where T : IFoo, IBar { }

Frob(new Thing());

This is complicated, but doable using current constraints of the framework. An anonymous type can be generated:

class <mangled>Thing_IFoo_IBar : IFoo, IBar
{
  internal <mangled>Thing_IFoo_IBar(Thing thing) { this._thing = thing; }
  readonly Thing _thing;

  void IFoo.Foo() { ... } // these member(s) are copied from, or call into, FooThing
  void IBar.Bar() { ... } // these member(s) are copied from, or call into, BarThing
}
Frob(new <mangled>Thing_IFoo_IBar(new Thing()));

The same can be done for generic types, etc. Yes, it's complicated, but unlike roles, it's very possible.

[CyrusNajmabadi]

The main motivation example

This was just one example. It's not the main motivation. We discussed in the LDM that there were definitely plenty of scenarios where you'd still want adapters in a strongly typed way that would be sensible.

[sab39]

@TahirAhmadov That works, more or less, for the specific example I gave, but what if Frob<T> had other constraints like where T : class or where T : struct or where T : new() or where T : SomeBaseClass? What about if it were Frob<T, T2> where T2 : T? In general it's not actually possible to generate an anonymous type that can meet all possible constraints that T would meet and also implement IFoo and IBar. This suggests to me that it's not possible to fully support this scenario without runtime assistance.

[TahirAhmadov]

The main motivation example

This was just one example. It's not the main motivation. We discussed in the LDM that there were definitely plenty of scenarios where you'd still want adapters in a strongly typed way that would be sensible.

If it's not the main motivation, surely it shouldn't be the one discussed in the OP, should it?

[CyrusNajmabadi]

The OP is simply showing a demonstration. This is a broad topic and we need to spend a ton more time on it prior to even getting close to a place where we could write something up that was fully fleshed out and chock full of examples and whatnot.

[TahirAhmadov]

@TahirAhmadov That works, more or less, for the specific example I gave, but what if Frob<T> had other constraints like where T : class or where T : struct or where T : new() or where T : SomeBaseClass? What about if it were Frob<T, T2> where T2 : T? In general it's not actually possible to generate an anonymous type that can meet all possible constraints that T would meet and also implement IFoo and IBar. This suggests to me that it's not possible to fully support this scenario without runtime assistance.

The where T : class constraint simply rejects Thing extensions if Thing doesn't satisfy the constraints. The where T : new() rejects all extensions outright. where T : SomeBaseClass also rejects extensions of Thing because it's a different type. Frob<T, T2> where T2 : T is completely irrelevant.

[BhaaLseN]

Back with .NET Framework, I've often ran into situations where i wanted a Math.Clamp<T>(T value, T min, T max), Math.Max(TimeSpan val1, TimeSpan val2) or Path.GetRelativePath(...) for discoverability; but there was no way for me to get this done. Same with string.Contains(string, StringComparison) etc. except as instance extension (which is somewhat taken care of by extension methods though.)
Nowadays most are in there since either .NET Core or .NET 5/6, but it would feel more natural to simply extend the existing classes (with a very high-up namespace inside the project, so its most likely in scope all the time; or with a global using for example) when another one of those situations comes up. At least compare to MathEx, MathUtilities, PathHelpers etc. which often aren't as obvious.

The only thing I don't quite get is why we need two keywords here, role and extension. They mean different things if you talk about them, sure, but does this actually matter once you write the code? I'd assume they'll be lowered to virtually the same thing during compilation after all, and I can practically hear the "what's the difference" question coming when I present this to my team during a knowledge transfer meeting.

[TahirAhmadov]

The OP is simply showing a demonstration. This is a broad topic and we need to spend a ton more time on it prior to even getting close to a place where we could write something up that was fully fleshed out and chock full of examples and whatnot.

That's the thing, it would be very interesting to see an example which would demonstrate how roles make something worthwhile possible or significantly easier, before effort is spent on prototypes, implementation planning, etc.

[CyrusNajmabadi]

That's fine. It's something we're working on at this moment '-). The point was raised and was something we intend to get to and write more on. I def don't want us to get the impression that it's just for that. Thanks!

[PeteMWilson]

I really like this, but I am disappointed the "for" keyword got left behind for the "extension" group.

[fitdev]

Not sure why this use case is not covered as it fails with CS9286:

public static class Extensions {
  //Define API:
  extension<TEnum>(TEnum) where TEnum : unmanaged, Enum {
    public static unsafe int BitSize {
      get {
        if (sizeof(TEnum) == 1) return 8;
        if (sizeof(TEnum) == 2) return 16;
        if (sizeof(TEnum) == 4) return 32;
        if (sizeof(TEnum) == 8) return 64;
        return 0;
      }
    }
  }
  //Consume API:
  void Foo() {
    var x = DayOfWeek.BitSize; // <- CS9286: 'DayOfWeek' does not contain a definition for 'BitSize' and no accessible extension member 'BitSize' for receiver of type 'DayOfWeek' could be found
 }
}

Yet, incidentally, the extension does show up in intellisense!

I think this feature would be very useful particularly for enums as it will aid API discoverability and because currently there is no way to define non-enum-member extensions on the enum type itself, whereas this can be done with any other kind of type (classes, structs, etc.)

[bernd5]

It works with version 5.0.0-1.25212.1

[fitdev]

I was using VS 17.14 Preview 3 not sure what Roslyn version it uses.

[jcouv]

To check what version of Roslyn is used, add #error version to your source

[fitdev]

Compiler version: '4.14.0-3.25202.5 (f76d6ab7)'. Language version: preview.

[fitdev]

So I take it that it is not a cslang issue but a Roslyn issue, and the above is really supported by the current design?

[znakeeye]

Why can't extension members have a backing field?

internal static class ActionExtensions
{
    extension<T>(Action<T>)
    {
        public static Action<T> OK=> _ => { };
        public static Action<T> CS9282 { get; } = _ => { };
    }
}

CS9282 Extension declarations can include only methods or properties

That's not a property? 🤔

[CyrusNajmabadi]

Why can't extension members have a backing field?

Because there's no place to actually efficiently store the field.

The only mechanism .Net allows for, at this time, is using something like a ConditionalWeakTable for this purpose. And in no circumstances will teh compiler be backing any common language feature in a way that uses a CWT. It is an option for you to use explicitly, if it is an acceptable solution for your particular domain.

[HaloFour]

It sounded like there was interest in supporting static extension auto-properties, fields and constants, since there is no storage concern.

[martin-steinhoefer]

Why can't extension members have a backing field?

internal static class ActionExtensions
{
    extension<T>(Action<T>)
    {
        public static Action<T> OK=> _ => { };
        public static Action<T> CS9282 { get; } = _ => { };
    }
}

CS9282 Extension declarations can include only methods or properties

That's not a property? 🤔

The error message is a bit misleading, it should have said, that - for now - only methods and properties without backing fields are possible.

Support for static fields is planned, but not yet implemented - I think.

[hamarb123]

I'd be very greatful if the following (allowing ref on non-struct-constrained this parameters) could be considered to be allowed by the language team 🙂:
Example use case:

// Small number of APIs that every random number provider has to implement
interface IRandomProvider
{
    void NextBytes(Span<byte> bytes);
    void Skip(UInt128 valuesToSkip);
    // ...
}

// APIs which might be used on any instance, which have common logic built on top of those APIs
static class RandomProviderExtensions
{
    // error CS9300: The 'ref' receiver parameter of an extension block must be a value type or a generic type constrained to struct.
    //        \/ The issue is here
    extension(ref T provider) where T : IRandomProvider
    {
        public int NextInt32()
        {
            int value = 0;
            provider.NextBytes(MemoryMarshal.AsBytes(new Span<int>(ref value)));
            return value;
        }

        public int NextInt32(int minInclusive, int maxInclusive)
        {
            // Check arguments
            var range = (uint)(maxInclusive - minInclusive + 1);
            if (range == 0) return NextInt32();
            if (range == 1) return minInclusive;
            var mask = uint.RoundUpToPowerOf2(range) - 1;
            uint result;
            while (true)
            {
                result = (uint)NextInt32() & mask;
                if (result < range) break;
            }
            return (int)result + minInclusive;
        }

        public int NextInt32(int maxInclusive) => NextInt32(0, maxInclusive);

        // ... for all other data types, distribution types, etc.
    }
}

// Struct provider
struct MyRandom
{
    private int _state0, ...;
    public void NextBytes() => ...;
    // ...
}

// Class provider
class MyDifferentRandom
{
    private UInt128 _state;
    public void NextBytes() => ...;
    // ...
}

// Example usage
static void Shuffle<T, TRandomProvider>(Span<T> values, ref TRandomProvider provider) where TRandomProvider : IRandomProvider
{
    for (int i = values.Length - 1; i >= 1; i++)
    {
        var j = provider.NextInt32(i);
        (values[i], values[j]) = (values[j], values[i]);
    }
}

var mySpan = ...;
MyRandom r = ...; // or MyDifferentRandom
Shuffle(mySpan, ref r); // Will work with any random provider

// Example usage

MyRandom r1 = ...;
MyDiffererentRandom r2 = ...;
MyOtherDiffererentRandom r3 = ...;
// ...

// They all have implementations for NextInt32 that work immediately, along with any other common functionality I need.
// They don't need to be boxed to use it, nor do they need to repeat the same code over and over, nor do they need to be called
// in a less nice way, such as via a static method, nor do they need to all explicitly define the method themselves (lots of duplication), etc.
r1.NextByte(); // Imagine I used these for literally any use case for random number generators
r2.NextInt32();
r3.NextGaussian();
// ...

Now I will list some other options that you could do something similar with today, but which are much less preferable to me for my use cases for the reasons I list.

2 seperate generic methods, one which takes by ref & is constrained to struct, and another which just takes an IRandomProvider:

• This won't work in generic contexts, I'll have to have 2 copies of any method I in which I want to use one of my core methods like NextInt32, one for each version
• This will either require code/logic duplication, or require weird wrappers to work around the code duplication

Interface DIM:

• This can end up causing a bunch of boxing (unless I do the following dotpoints), some of which may be elidable by the JIT, but other of which likely wouldn't be, which would be a non-starter
• It would still require it to be defined on any concrete type type that implements the interface if I wanted to be able to call it on an instance of that concrete type, which either implies code/logic duplication, or weird wrappers. (and potentially even more of these than the previous solution)
• Wouldn't work on structs correctly at all, if they need to mutate, (rather than just not being available w/o casting to interface type), unless they manually implement the method themselves anyway - so I'm not really gaining anything

Putting in a wrapper struct or ref struct, which we always take by ref or value (correspondingly), and then defining the extensions on that:

• This is undesirable immediately because I would have to write MyWrapper.Create(ref x) or similar, before I can access .NextInt32() in any context at all
• If you defined the extensions on any struct still, and had the wrapper implement the interface, then it would be less bad, but would still be nasty for reference type providers
• If you also define extension/s to work on reference types, which just wrap and forward (which is unideal to start with), then you will accidentally be making a pit of failure where you may silently use those versions in contexts where that would be incorrect, such as if I took ref TProvider provider, and forgot to wrap before calling .NextInt32(), etc.
• It may require marshalling depending on whether I stored the value or the original ref itself

Making it a static method:

• This one only has 1 problem, aesthetics/findability/etc. (i.e., the exact problem that extensions are meant to solve): these are functionally & logically instance methods, but just not declared on the type itself - but there's no way to actually declare these as functionally instance methods in the generic context - in fact, even the existing behaviour with taking this by reference for structs doesn't match what happens with actual instance methods that mutate, since default(MyStruct) /*or any other r-value*/ .MyMutatingMethod() works, but only if it's a real instance method, it doesn't work for extension ones (this should also be fixed imo)
• I could write RandomUtils.NextInt32(...) & make it work, but imo it's not really different to having to write Enumerable.First(myEnumerable) vs myEnumerable.First(), and I hate having to call static things to do what is conceptually an instance's job - I'm very excited we're fixing the limitations of extensions for some cases, such as allowing properties, static members, etc., but I think not being able to mutate in it properly generically is a big gap, since it means you can't actually add something that acts like an instance member (in fact, it would actually be even more problematic for property setters on generic types, as they are likely completely nonsensical in many cases for structs w/o being able to mutate the instance)

In summary, the main reason I think taking ref T for this is the correct solution it that it is conceptually (& literally, at an IL level, other than the obvious call (extension) vs constrained. callvirt (constrained generic)) exactly the same as calling an interface member in a generic context, which is what I am conceptually actually wanting to define (e.g., NextInt32 is conceptually an instance method, which mutates state, but I want to share the logic for how to extract that from the simple interface for all the random providers, as there's a lot of things I may want to generate from any one of them).

My understanding of why it's not allowed currently is because it may be confusing if I called a method on my class & the instance got replaced with another - this is an understandable concern, but I think not having a mechanism to allow defining instance members on generic types is more problematic (it's something I run into somewhat often, when working with mutable structs + interfaces + generics), and additionally, we have other language features which can be abused / used incorrectly / etc. (which for this feature, I'd argue that re-assigning this when T is reference type probably is, at least most of the time), but that exist to fill a need (e.g., dynamic, unsafe, stackalloc, source generators, overload resolution priority, etc. - I'd also argue the risks of this proposal, even when used incorrectly, are far lower than for some of the ones I just mentioned). I think the ability to define instance members on generic type parameters constrained to an interface that do something meaningful for non-readonly structs would be great, as it would provide an alternative to DIMs where DIM isn't really what you want (and also doesn't really achieve it, since you'd still have to declare on all implementing types if you wanted it to work on concrete types), and what you actually want is to logically define a method (or property, etc., obviously) that operates on any type that implements that interface, including structs which need to mutate, but are logically instance members.

Thanks for reading that & (hopefully) considering it :)

[fitdev]

How about constant extension members?

I was wondering if there are any plans for extension constants. These may be just as useful as static extension members. Albeit this is just syntactic sugar, API discoverability aspect is important.

[CyrusNajmabadi]

I'm just worried about that particular point of a feature that is in current work and soon about to ship.

Can you clarify what your worry is with static fields and the current design of extensions? I don't see anything that would inhibit supporting such a feature in the future.

[martin-steinhoefer]

I'm just worried about that particular point of a feature that is in current work and soon about to ship.

Can you clarify what your worry is with static fields and the current design of extensions? I don't see anything that would inhibit supporting such a feature in the future.

I try to explain... however, I'm no expert in lowering. I hope, that I can express myself clearly.

As I understood, an extension block is lowered as a hidden type (in our case generic). A static field which itself is generic, would then be a field in that type - I guess. Another extension block within the same container class can declare another field (generic). As extension blocks aren't visibility barriers, one can access members declared in one extension block from another.

static class Extensions
{
    extension<T>(C<T> receiver)
    {
        private static T _field = ...
        public void M(T value) =>_field = value;  // access to _field is no problem here I guess, the type parameter just 'flows' down
        public void N<U>(U value) => R<T,U>(...); // accessing R would be possible (it's a local declaration in the end)
    }
    extension<T,U>(C<T,U> receiver)
    {
        private static U _anotherField = ...
        public void R() =>...
    }
}

But to access _anotherField from N() one has to specify 2 type parameters which are required to get the correct specialization of the hidden type (which is generic), and only one of them would 'flow'. How would one do that?

One side note as information. I find myself often writing extension methods with the same name and similar signature for a variety of receivers. I would end up building a tree of invocations from one extension block to another. So to me, that's not un-common.

[CyrusNajmabadi]

But to access _anotherField from N()

You'd specify C<T, Whatever> from within N to specify the instantiation of C<,> that you were accessing the static off of.

[martin-steinhoefer]

But to access _anotherField from N()

You'd specify C<T, Whatever> from within N to specify the instantiation of C<,> that you were accessing the static off of.

Oh... I understand. Sorry for any inconvenience and thank you for your patience.

[CyrusNajmabadi]

But to access _anotherField from N()

You'd specify C<T, Whatever> from within N to specify the instantiation of C<,> that you were accessing the static off of.

Oh... I understand. Sorry for any inconvenience and thank you for your patience.

No inconvenience. Glad I could help here.

[Blaisor]

It seems the C# Language Design Team are in dire need for a nice, intuitive syntax wich also supports all major cases while keeping binary compatibility with previous extension methods. So I went back and reread the comments from this discussion which have formed the state of the current language proposal as well as user-submitted ideas and concerns to address as many issues as possible. Here is my take of a possible syntax which could solve most goals:

This is the very first example for Extension Members from the specs, rewritten in my proposed way:

public extension<T> E for (T[] ts)
{
    public bool M1(T t) => ts.Contains(t);
}

Note that this isn't just a syntactical sugar over the current proposal, because this would generate a static class with a generic type parameter:

[GeneratedCode]
public static class E<T>
{
    public static bool M1(T[] ts, T t) => ts.Contains(t);
}

instead of

[GeneratedCode]
public static class E
{
    public static bool M1<T>(T[] ts, T t) => ts.Contains(t);
}

In this way we could preserve the arity of the generic arguments for the method, a major issue raised here: #8696 (comment)

Furthermore, theoretically you would be able to omit the name of the extension and just rely on what the compiler can come up with:

public extension<T> for (T[] ts)
{
    public bool M1(T t) => ts.Contains(t);
}

Which would be very similar to classless "extension groups" (a suggestion from Mads Torgersen's presentation).

If needed, you could also alternatively write extension members individually in normal static class:

public static class Enumerable
{
    // Extension method with generic arity of 1
    public extension<TSource> IEnumerable<TSource> Where(Func<TSource, bool> predicate)
        for (IEnumerable<TSource> source)
    {
        ...
    }

    // Extension method with generic arity of 2
    public extension<TSource, TResult> IEnumerable<TResult> Select(Func<TSource, int, TResult> selector)
        for (IEnumerable<TSource> source)
    {
        ...
    }

    // Extension method with generic contsraint
    public extension<TSource> IEnumerable<TSource> Average()
        for (IEnumerable<TSource> source)
        where TSource : INumberBase<TSource>
    {
        ...
    }

    // Extension property
    public extension<TSource> bool IsEmpty for (IReadOnlyCollection<TSource> source) => source.Count == 0;

    // Extension operator
    public extension<TSource> static IEnumerable<TSource> operator +(IEnumerable<TSource> first, IEnumerable<TSource> second)
        for IEnumerable<TSource> // Note the lack of parentheses as they are not needed here
    {
        return source.Concat(other);
    }

    // Classic extension method
    public static IEnumerable<TResult> Cast<TResult>(this IEnumerable source) { ... }
    
    // Non-extension member
    public static IEnumerable<int> Range(int start, int count) { ... } 
}

In this way you can get binary compatibility with the old extension methods, but you would also lose those groupings, though. However, you can always add support for that syntax later for those who are interested in such "sugar".

Here is the Enumerable extension but written in a top-level form:

public extension<TSource> Enumerable for (IEnumerable<TSource> source)
{
    public IEnumerable<TSource> Where(Func<TSource, bool> predicate)
    {
        ...
    }

    public IEnumerable<TResult> Select<TResult>(Func<TSource, int, TResult> selector)
    {
        ...
    }

    public IEnumerable<TResult> OfType<TResult>()
        where TResult : TSource
    {
        ...
    }
}

Note that this extension can't include the Average() method from the previous example (not even in a partial way) because it has an extra generic constraint on its receiver parameter. However, writing top-level extensions would a huge advantage: you would be able to call the OfType<TResult>() method with only one generic argument (which is not possible in the current proposal):

IEnumerable<Animal> animals = [dog, cat, goldfish];
IEnumerable<Mammal> mammals = animals.OfType<Mammal>();

because it would translate to

IEnumerable<Mammal> mammals = Enumerable<Animal>.OfType<Mammal>(animals);

And finally, here is an example for static only members:

public extension MathExtensions for Math // Note the lack of parentheses as they are not needed here
{
    public const double GoldenRatio = 1.61803398875;

    public static BigInteger Pow(BigInteger value, int exponent)
    {
        return BigInteger.Pow(value, exponent);
    }

    public static T Pow<T>(T value, T exponent)
        where T : IPowerFunctions<T>
    {
        return T.Pow(value, exponent);
    }
}

[Blaisor]

But why did you propose that syntax then? It's either top-level (i.e. type) or member-based. Did I miss something?

In my version I combined the container class and the extension groups together into one extension type, so they would behave like a type.

[chrisoverzero]

But why do we have to add <summary> to the extension blocks?

Who says you do?

[Blaisor]

But why do we have to add <summary> to the extension blocks?

Who says you do?

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/extensions#xml-docs

[martin-steinhoefer]

But why did you propose that syntax then? It's either top-level (i.e. type) or member-based. Did I miss something?

In my version I combined the container class and the extension groups together into one extension type, so they would behave like a type.

I did see that, and I like it. Your proposal is one of the few, that addresses most of the problems with syntax I could feel comfortable with.

[kevin-s-diaz]

Why didn't you just go with this syntax man... So disappointing.

[aromaa]

Could we have 2-phase lookup by introducing discards for generic arguments that could use the old 1-phase lookup?

extension(IEnumerable<_>)
{
    // 1-phase lookup, for compat, generic argument in the method declaration
    public static IEnumerable<T> M<T>(out T t) => ...;
}

extension<T>(IEnumerable<T>)
{
    // 2-phase lookup, generic argument in the extension declaration
    public static IEnumerable<T> M(out T t) => ...;
}

Originally posted in dotnet/roslyn#78415 (comment).

[333fred]

That's #8968.

[NinoFloris]

@333fred the suggestion you replied to is about the definition side influencing which kind of generic inference will happen.

Personally I don't think it's a good idea to predicate such behavior on a small and non obvious syntactic difference (If we need a mechanism at all I would much prefer an attribute with a clear name instead)

[sab39]

For whatever it's worth, I posted a suggestion the other day of another way we could get faux two-phase lookup in the short term, until the real thing can be implemented later.

[nike4613]

I just ran into dotnet/roslyn#78753 when playing with the preview, and I find this behavior unintuitive. Intuitively, the extension method + extension property feels more like extension method + instance property than like instance method + instance property. Some part of this likely comes from the error message seeming to indicate that something wasn't found at all, when in fact the error is an ambiguous result.

This limitation does also block a migration path for some code (which I, at least, see somewhat frequently).

Previously, if you wanted a property-like thing as an extension, you'd write something like this (using the case I ran into as an example):

public static bool IsByRefLike(this Type type) => ...

// called like
type.IsByRefLike()

This has 2 downsides:

1. As a method call, it can't be used in a pattern, which sucks.
2. For this particular case, polyfilling missing functionality downlevel, you must change all usesites to be explicitly a method call, and thus have "normal" code (that was written targeting, say, .NET 9) must look different from "portable" code that can target mostly any framework.

The ideal upgrade path for this is to keep (but hide) the existing extension method, while adding an extension property of the same name. This then allows the natural code to work, and gives access to pattern matching and such.

Per @jcouv's response, this is not allowed under current rules, which is a shame. It would be very nice if there were some resolution. I think the natural one is to allow resolution here, but I would accept even a magic "don't consider this method during overload resolution" attribute (or some other similar cudgel).

[Blaisor]

This is really unfortunate because you can't use the following:

public static class Extensions
{
    extension<T>(IEnumerable<T> enumerable)
    {
        public bool IsEmpty() => !enumerable.Any();
    }

    extension<T>(IReadOnlyCollection<T> collection)
    {
        public bool IsEmpty => collection.Count == 0;
    }
}

It shows up solely as a property in Visual Studio's IntelliSense (I'd expect both to be there just like List<T>.Count). However, It works as expected if you convert the IsEmpty property into a method.

[kurt-rudin]

I updated Visual Studio to Version 17.14.2 this week and since then, following code leads to a compile error:

    [GeneratedCode("xsd", "4.7.3081.0")]
    [Serializable]
    [DebuggerStepThrough]
    [DesignerCategory("code")]
    [XmlType(AnonymousType = true, Namespace = "http://www.ech.ch/xmlns/eCH-0020/3")]
    [XmlRoot(Namespace = "http://www.ech.ch/xmlns/eCH-0020/3", IsNullable = false)]
    public class extension
    {
        private XmlElement[] anyField;

        /// <remarks/>
        [XmlAnyElement]
        public XmlElement[] Any
        {
            get
            {
                return anyField;
            }
            set
            {
                anyField = value;
            }
        }
    }
    
     [GeneratedCode("xsd", "4.7.3081.0")]
    [Serializable]
    [DebuggerStepThrough]
    [DesignerCategory("code")]
    [XmlType(Namespace = "http://www.ech.ch/xmlns/eCH-0020/3")]
    public class eventChangeMatrimonialInheritanceArrangement
    {
        private extension extensionField;

        public extension extension
        {
            get
            {
                return extensionField;
            }
            set
            {
                extensionField = value;
            }
        }
    }

The error is "error CS9281: Extension declarations may not have a name." at the Line "private extension extensionField;".

I highly suspect, that a recent PR about "Extension Members" is the culprit. I was a bit stumped, because I never saw a hint in the release notes about "extension" suddenly being a keyword. It's easy to fix in my case by prefixing the reference to the extension class with an @ like this:

    public class eventChangeMatrimonialInheritanceArrangement
    {
        private @extension extensionField;

        public @extension extension
        {
            get
            {
                return extensionField;
            }
            set
            {
                extensionField = value;
            }
        }
    }

Maybe this helps someone who stumbles into this issue, too.

[thomaslevesque]

I suspect this is a compiler bug. You should report it in the Roslyn repo

[jnm2]

It's by design: https://github.com/dotnet/csharplang/blob/main/proposals/extensions.md#breaking-changes

If you name a type with all lowercase letters, the compiler has been warning you since langversion 11 that you're in breakable territory: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/warning-waves#cs8981---the-type-name-only-contains-lower-cased-ascii-characters

[mharthoorn]

The new extension syntax is more relaxed in naming restrictions than normal classes.
A normal class cannot have an instance and a static method with the same name:

class Greet
{
    public void Hello() => Console.WriteLine("Hello");
    public static void Hello() => Console.WriteLine("Hello"); 
    // Error: Type 'Greet' already defines a member called 'Hello' with the same parameter types
}

A similar restriction is enforced when creating an instance and static extension method:

static class GreetExtensions
{
    extension(string s)
    {
        public void Hello() => Console.WriteLine("Hello");
        public static void Hello() => Console.WriteLine("Hello"); 
        // Error: Type 'GreetExtensions' already defines a member called 'Hello' with the same parameter types
    }
}

However, If you put these extension methods in two separate classes, the compiler (VS 1714.2) has no issue with it:

static class GreetExtensions1
{
    extension(string s)
    {
        public void Hello() => Console.WriteLine($"Hello {s}"); // no error
    }
}

static class GreetExtensions2
{
    extension(string)
    {
        public static void Hello() => Console.WriteLine("Hello"); // no error
    }
}

That seems like an inconsistency. Is the original class restriction still needed.
Or if there still is good reason for it: shouldn't it also apply to extension methods?

[IS4Code]

You have two distinct methods in two distinct classes, I don't think the compiler should have an issue with it. Classic extension methods also behave this way.

In addition, why should this be an error in the first place? The extensions are only in effect when you use using, and you can import them individually via using static, so it's not like you cannot use them. Upholding consistency is no good when it restricts existing features.

[jnm2]

Here are the meeting notes where this question was considered: https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-03-24.md#signature-conflict-rules

The behavior as implemented today was considered to be the consistent approach. As @IS4Code mentions, the behavior is the same between classic extensions and new extensions when the extensions are declared in different containing classes. The behavior is also consistent with the existing language rules about declaring instance and static methods in the same type.

It's also a safe approach; when unsure which way to go, you can start with more restrictive rules and relax them later once there is a motivation for the investment.

[martin-steinhoefer]

That seems like an inconsistency. Is the original class restriction still needed. Or if there still is good reason for it: shouldn't it also apply to extension methods?

That is an interesting view. Via extensions one can declare things, that could not be declared as members.
However, that was the case with extension methods too (one could declare colliding signatures in separate classes). That's why disambiguation exist. The new feature just took that to a new level (now one can have conflicts between extensions with static methods and properties too).
I would not call it inconsistency.

[sab39]

With this feature I can finally write the int?.Parse(...) extension method I've wanted since 2005:

public static class NullParseExtensions
{
    extension<T>(T?) where T : struct, IParsable<T>
    {
        public static T? Parse(string? str, IFormatProvider? format = null) => string.IsNullOrEmpty(str) ? null : T.Parse(str, format);
    }
}

but, crushingly, it doesn't quite work: Nullable<int>.Parse(str) works fine, but the compiler sees int?.Parse(str) as a null-conditional method call and complains that the left hand side can't be a type. Any chance to allow this syntax for calling static extension members on Nullable<T>?

[IS4Code]

It's not an issue with just ?.. int[].Equals is also not valid.

[sab39]

I mean I'm sure it's possible, but why not just write int.ParseOrNull?

Really just style / aesthetics / personal taste at this point. For sab-circa-2005 it was to simplify codegen for things like

public $type $name { get; set; }
...
this.$name = $type.Parse(...);

[HaloFour]

I kinda prefer extension "overloads" to TryParse:

int? result = int.TryParse(str);

[jnm2]

Fwiw, int?.Xyz is really hard for me to parse as (int?).Xyz. My brain wants to see it as (int)?.Xyz. If I didn't know any better, int.Xyz is where I would go looking for extension methods that return int?.

[NetMage]

It is too bad (int?).Parse(...) doesn't work.

BTW, it seems like this doesn't work with current extension methods either, so it is not a new issue.

[kevin-s-diaz]

Why not go with a less indented/verbose syntax? This is ugly IMO.

[nvmkpk]

They want the existing extension method implementations to update to use this new syntax with minimal impact. But why? The existing syntax is not being removed and can still be used. If they want to use new features (like static extension methods), then they should use new syntax that differs from current.

[HaloFour]

It's not just migration, it's also how extensions are organized. We have a 20 year old ecosystem here, having to completely change how extensions are organized in that ecosystem to placate some stylistic concerns over a level of indentation seems silly.

[CyrusNajmabadi]

But why?

The same reason we have always wanted classic features to be able to move forward. So you don't hve to have a mishmash of different approaches in your codebase. We did the same, for example, when adding lambdas (Even through as had anonymous delegates). We wanted virtually all existing cases to be subsumed by the new system. The same applies here.

This is also very relevant for things like organization. If you're extending some type, then having to have all your new properties, static methods, indexers, constructors, and operators in one location, while instance-extension-methods live elsewhere does not align with how people commonly will want to organize things.

then they should use new syntax that differs from current.

We don't believe people should have to live with a split where tons of existing systems are forced into one classic form, and all the new code is done entirely different. We see this in other languages, and view it negatively. If you are using extensions, you should have a cohesive experience across the whole language where you can pick one form that then works consistently.

[nvmkpk]

It's not just migration, it's also how extensions are organized. We have a 20 year old ecosystem here, having to completely change how extensions are organized in that ecosystem to placate some stylistic concerns over a level of indentation seems silly.

I totally understand but don't discount indentation, it is important and defines how we split long lines. More level of indentation means less content will fit in one line. For that very reason I just took extra effort to switch to file scoped namespaces in all of my code as soon as it was available to me.

[CyrusNajmabadi]

I totally understand but don't discount indentation

We haven't discounted it.

[lgztx96]

Pointer type? I accidentally discovered that it actually works. Is this within the intended design? Is there anything I should be aware of?
After updating to Preview 5, it no longer works.

[IS4Code]

That's sad, would be nice to have extensions on pointers.

[AsakusaRinne]

Hi, I tried this new feature with .NET 10 preview 5 and it's great! However I got errors when adding an operator extension according to the proposal (operator section).

class Something<T> where T : INumber<T>
{
}


static class SomethingExtension
{
    extension<T>(Something<T>) where T : INumber<T>
    {
        public static Something<T> operator +(Something<T> left, Something<T> right)
        {
            return new Something<T>();
        }
    }
}

The errors are:

1. CS0563
2. CS9282

Am I doing something wrong, or this feature has not been implemented?

[jcouv]

The extension operators feature was only merged last week, so it's likely not available in the build you're using. It'll be available in the next update

[AsakusaRinne]

That's great! Looking forward to it

[znakeeye]

Maybe time to get these extensions related warnings fixed?

• CA1822 false positive for C#14 extension method roslyn-analyzers#7646
• IDE0055 false positive for C# 14 extension methods roslyn#78422

You hit these immediately when trying out the new extensions feature, but surprisingly few seem to complain. Code analysis, a rarely used feature?

[CyrusNajmabadi]

@znakeeye PRs welcome.