Extension indexers

[jcouv]

Extension indexers didn't make it into C# 14.
There are probably some other member kinds that we'll consider in C# 15 as well (const).
Championed proposal: #9856

[jnm2]

I'd be interested in extension conversion operators. A use case is creating a conversion operator to or from string to ReadOnlySpan<char> (or a similar nonsystem type). Due to the other type being generic, the conversion operator could never be declared in the generic type, and we can't declare conversion operators in System.String either because that's a system type. Extension conversion operators would help round out the polyfill scenario as well as providing a general solution to the problem of conversion to a subset of a generic user-defined type.

[333fred]

string to ReadOnlySpan

This particular conversion was defined as part of first-class spans.

[fitdev]

I second the need for conversion operators - both implicit and explicit, but especially implicit ones! This was the main reason I was looking forward to extension members. Hopefully you can add them in C# 15.

This is especially useful if you are dealing with some 3rd-party library type often and have a need to use it (convert it) to one of your own types or BCL's many times. Implicit conversion operator would be ideal in such a case, as you cannot add an operator to a 3rd-party type from another library.

[hez2010]

How about adding extension constructors and extension events as well?

As for extension constructors, it can be used for creating some classes that have required members without a constructor, so that for an existing class:

class Foo
{
    public required int A { get; init; }
    public required string B { get; init; }
}

I can use extension to create a constructor for Foo:

extension (Foo)
{
    [SetsRequiredMembers]
    public Foo(int a, string b)
    {
        this.A = a;
        this.B = b;
    }
}

Then I can write new Foo(42, "foo") instead of new Foo { A = 42, B = "foo" }.

With extension constructors I can even create constructors for some specified generic instantiations. For example, if I only want to allow NumberComparer<T> where T is floating point value to have a parameter of epsilon, I can now:

extension<T>(NumberComparer<T>) where T : IFloatingPoint<T>
{
    public NumberComparer(T epsilon)
    {
        ...
    }
}

so that only for types like NumberComparer<float>, NumberComparer<double> will have the epsilon parameter in the constructor, while other instantiations will not.

And for extension events, it's helpful when you want to extend a new kind of event for an existing control, and use it as an event filter for convenience:

extension (ItemsControl ic)
{
    public event EventHandler<ClickedEventArgs> OnDoubleClicked
    {
        add => ic.OnClicked += (sender, args) => { if (args.Kind == ClickedKind.DoubleClick) value(sender, args); }
        remove => ...;
    }
}

[jnm2]

What is an example of how the body of the NumberComparer ctor might use the epsilon?

[hez2010]

It can instantiate and return a FloatingPointNumberComparer<T> which derives from NumberComparer<T>:

extension<T>(NumberComparer<T>) where T : IFloatingPoint<T>
{
    public NumberComparer(T epsilon)
    {
        return new FloatingPointNumberComparer<T>(epsilon);
    }
}

where the NumberComparer<T> itself can even be an abstract class, so that we are able to create an instance using only the abstract class without finding its implementation class, as long as we have the desired arguments and type arguments by the extensions. Note that with the enhanced late devirtualization in .NET 10, this case can be easily optimized away by the JIT so that we don't pay any abstraction cost.

[TahirAhmadov]

This feels extremely iffy, doing new SomethingBase(...) when it's abstract class SomethingBase, even as an extension. I think an extension static method is much more suitable here.

However, I do like the idea of extension constructors:

extension(StringBuilder @this)
{
  public StringBuilder(Foo foo) : this(foo.ToString())
  {
    @this.Capacity = 123; 
  }
}

[jnm2]

@hez2010 The ability to return a derived type would conflict with what a constructor currently is, which is a chainable void instance method. In C# terms, while object creation syntax creates a new instance, a constructor does not return an instance today. This would be a large departure, and extensions could consider leaning into "extension constructors are merely static factory methods," but why not use a static method if what you want is a derived instance? That is the established pattern.

(Not to mention that your first example of a constructor is then missing the statement that returns an instance.)