[Discussion]: Extensions

[333fred]

Discussed in #5496

^{Originally posted by MadsTorgersen November 30, 2021}
https://github.com/dotnet/csharplang/blob/main/proposals/csharp-14.0/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!

[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 https://github.com/dotnet/roslyn/issues/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.

[ThomasTheMor]

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.

[SanftMonster]

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

[SanftMonster]

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.

[ViIvanov]

Is it a "known issue" with new extension members and CallerArgumentExpression attribute?

I am trying to convert the following method into an extension member:

public static class MyExtensions
{
  public static string GetRequiredToString<T>(this T? value, [CallerArgumentExpression(nameof(value))] string? paramName = null) {
    ArgumentNullException.ThrowIfNull(value, paramName);
    return value.ToString() ?? "";
  }

  // Re-writing above as:
  extension<T>(T? value) {
    public string GetNewRequiredToString([CallerArgumentExpression(nameof(value))] string? paramName = null) {
      ArgumentNullException.ThrowIfNull(value, paramName);
      return value.ToString() ?? "";
    }
  }
}

and I got the "warning CS8963: The CallerArgumentExpressionAttribute applied to parameter 'paramName' will have no effect. It is applied with an invalid parameter name.".

I understand the issue and was not able to find a discussion about that.
Is it related to #9655, or does it make sense to start a new discussion, or is it better to ask here about allowing nameof(receiver_parameter_identifier) in the extension method declaration?

[jcouv]

Please file a roslyn issue. This looks like a bug

[ViIvanov]

Added dotnet/roslyn#80239

[FaustVX]

I've already filed a similar issue dotnet/roslyn#78137 for InterpolatedStringHandlerArgument

[Balkoth]

There seems to be no way to document the extension block itself. Also generic parameters can not be documented. Was this completely forgotten? Or is VS2026 tooling not up to the task?

So how is this supposed to be done? This looks ugly and contains duplicate stuff. While tooltips are showing, automatic tooling by entering /// does not work:

/// <summary>
/// Extensions for the <see cref="IQueryable{T}"/> interface.
/// </summary>
public static class IQueryableExtensions
{
  /// <summary>
  /// Extensions for the <see cref="IQueryable{T}"/> interface.
  /// </summary>
  /// <param name="source">An <see cref="IQueryable{T}"/> to create an <see cref="ImmutableList{T}"/> from.</param>
  /// <typeparam name="TSource">The type of the elements of <paramref name="source"/>.</typeparam>
  extension<TSource>(IQueryable<TSource> source)
  {
    /// <summary>
    /// Creates an <see cref="ImmutableList{T}"/> from an <see cref="IQueryable{T}"/>.
    /// </summary>
    /// <returns>An <see cref="ImmutableList{T}" /> that contains elements from the input sequence.</returns>
    public ImmutableList<TSource> ToMyImmutableList() => source.ToImmutableList();
  }
}

[martin-steinhoefer]

Well - introducing a completely new code element (neither type nor member but 'between' them) introduces lot of complications...
...however the team went for that road knowingly - so you might just wait for a solution. Sooner or later they will present a solution (I pray for sooner).

[IS4Code]

Honestly I don't see any problem with how this works at the moment. extension is not a concrete entity, it is a section that indicates how the members inside are parametrized, and so there is no code element to attach the summary to.

Of course typing /// should bring up the default documentation sections in either case.

[Balkoth]

It is a problem, because if you do not document the typeparam like i did in the second example, you get obviously no documentation an no intellisense for it.

[ufcpp]

Seems done in 18.3 milestone.
dotnet/roslyn#76130

[jcouv]

I believe xml docs were done in 18.0 milestone modulo some bugs (last relevant compiler PR). Here's an example to illustrate.
On the other hand, IDE completion will be in 18.3.

[egvijayanand]

Why do extension members still require the LangVersion to be set to preview for it to work?

I'm trying to define an extension property in a .NET 10 targeted project, but it won't compile unless the LangVersion is set to preview.

[egvijayanand]

They don't. Are you attempting to use the final of .NET 10 in VS 2022?

Yes, using it in VS2022. But I can’t find any mention of it on the Docs page here. Consider adding a note in there.

[BlinD-HuNTeR]

You need VS2026 in order to use C# 14 and .NET 10. VS 2022 only supports C# 13 and .NET 9, that's why these are still "preview" features for you.

[333fred]

They don't. Are you attempting to use the final of .NET 10 in VS 2022?

Yes, using it in VS2022. But I can’t find any mention of it on the Docs page here. Consider adding a note in there.

The very first paragraph:

[egvijayanand]

If it doesn’t work with VS2022, there’s no point in discussing further. It does work, but with a caveat: beginners may find it confusing. Hence, I suggest adding a note.

[CyrusNajmabadi]

@egvijayanand you can suggest notes over at dotnet/docs. They own this experience. Thanks :)

[IanKemp]

Are implicit and/or explicit operators intended to be supported for extending? I'm getting CS9282 when trying either, but haven't been able to find a conclusive source as to whether that's expected.

[jcouv]

Extension conversion operators are not supported in C# 14:
"Does not cover user-defined implicit and explicit conversion operators, which are not yet designed or planned."
https://github.com/dotnet/csharplang/blob/main/proposals/csharp-14.0/extension-operators.md#extension-operators

[IanKemp]

Thank you sir!

[ds5678]

Is there a plan to support a form that reduces nesting when a extension type only has extensions for a single base type?

// Before
internal static class TokenTypeExtensions
{
	extension(TokenType type)
	{
	}
}

// After
internal extension TokenTypeExtensions(TokenType type)
{
}

[jcouv]

No plans at the moment

[ufcpp]

see https://github.com/dotnet/csharplang/blob/0f6e1419716ee0be1f88efa57683bf0546036c36/proposals/top-level-members.md

[nvmkpk]

It is unfortunate, this additional indentation is preventing me from using this feature.

[Pxtl]

Link is 404, what was this?

[333fred]

Fixed the link, thanks for pointing it out.