[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!

[sibber5]

Regarding the syntax, i think letting the user name the "source" is unnecessary and leads to inconsistent syntax.

Since we already have a keyword that refers to the current instance, this, I suggest a syntax like:

extension List<T>
{
    public IsEmpty => this.Count == 0;

    public static List<T> Create() => [];
}

this would also make extensions naturally work as a top level declaration, if that were to be added in the future.

to anyone seeing this in the future, i found LDM on using this: https://github.com/dotnet/csharplang/blob/main/meetings%2F2024%2FLDM-2024-11-13.md

[HaloFour]

This also falls under "future shorthand" conversations. Being able to explicitly name the receiver parameter is on the list of explicit goals.

See: #8696 (comment)

[tuscen]

I thought one of the goals was to be able to implement interfaces as extensions. Am I wrong? Will this feature be ever implemented?

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
}

extension UserExtensions(User user) : IEquatable<User>
{
    public bool Equals(User? other)
    {
        if (other is null) return false;
        return user.Username == other.Username && 
               user.Password == other.Password;
    }
}

[HaloFour]

Will this feature be ever implemented?

I believe it's still on the radar, in one form or another. There are a number of design concerns that need to be worked out, particularly around scoping and identity. Importantly the current syntax does not preclude extension implementation, although I wouldn't be surprised if that ends up becoming a feature of "roles" instead.

[Kuurama]

But if it makes into "roles" instead, we would need to override the types with another type instead of adding those new "traits" to the existing types. That's not the same feature, since that doesn't involve modifying the exact same type (at least, visually).

I would imagine that it could still work almost the same way if we make the "role" implementation a global using in the project, would that work though? It seems like more effort hum, and it wouldn't be convenient for libs to provide an easy way to extend existing types transparently, we would need our own GlobalUsing.cs with our own global usings as such:

global using User = MyRolesNamespace.UserEquatableRole;

I don't even know if a lib's implemented interface on a type would be discoverable on the project using that lib, i wonder if conflicts could occur between libs in the project, which interface to use then? Hum, I might need to learn more about the inner working of C#, it's a direction I'm more and more heading toward.

What are your thought on this? @HaloFour

[HaloFour]

I think these are the kinds of design questions that would need to be figured out.

I will say that my opinion is that such a feature should not actually affect the underlying type as far as the runtime is concerned. Attempting to do so would require also adding guardrails to ensure that you could never have more than one implementation between the same type and interface. Rust accomplishes this through coherence rules. One of those rules is that you are not permitted to add an implementation if both the type and the interface are declared outside of your project. I think such rules would seriously neuter extension implementation as a feature as I expect most use cases involve providing an implementation between types and interfaces declared outside of our projects.

To that end I think any mechanism to offer extension implementation requires scoping. Roles are one way, in that the implementation exists only when you are treating the underlying type as the role providing the implementation. I think extensions would have a similar scoping, as if the compiler is emitting an implicit operator between the receiver type and the interface. I also, personally, don't think concerns like identity are that important.

These are just my opinions, though. I expect that there are vastly different opinions amongst the folks on the language and runtime teams. :)

[Kuurama]

Thanks! Yes, the coherence rule seems perfect for that use case.
And to me, the extension interface implementation would allow libs to add behaviors to existing types considering their own internal interfaces, complying with the rule.
And the roles interface implementation would then allow to deal with said limitation with a different feature, for a different purpose (Since we would need to use the said role instead of the default extended type).

It would be great having both! (At least, just for thinking about it a bit).

[martin-steinhoefer]

I thought one of the goals was to be able to implement interfaces as extensions. Am I wrong? Will this feature be ever implemented?

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
}

extension UserExtensions(User user) : IEquatable<User>
{
    public bool Equals(User? other)
    {
        if (other is null) return false;
        return user.Username == other.Username && 
               user.Password == other.Password;
    }
}

What are you ecpecting from UserExtension? Is it value equivalence for User instances? (be aware, that this requires a proper GetHashCode implementation). How do you expect to behave Dictionary<User,string> or HashSet<User>? Should it respect your UserExtension?

[dotlogix]

Another question just came to my mind regarding extensions and different overloads of the same method with different where conditions. Let's say we have an extension:

public static class EqualExtensions {
    extension<T>(T self) where T : INumber<T>
    {
        public bool IsEqualTo(T other) => self == other;
    }
    
    extension<T>(T self) where T : IEquatable<T>
    {
        public bool IsEqualTo(T other) => self.Equals(other);
    }
}

Is this an allowed syntax now? It would define the same method name with the same generic arguments but different where conditions.
So to my understanding this would translate to sth like:

public static class EqualExtensions {
        public static bool IsEqualTo<T>(this T self, T other) where T : INumber<T> => self == other;

        public static bool IsEqualTo<T>(this T self, T other) where T : IEquatable<T> => self.Equals(other);
}

Which would be awesome if it would work but this is illegal C# as of now. Maybe a perfect opportunity to resolve this with different [OverloadResolutionPriorityAttribute]?

[jnm2]

If I remember right, these will conflict, but you can work around it by declaring them in separate static classes.

[linkdotnet]

I was fiddling around with some nice new features like operator overloading which may or may not come.

With that, I tried to "equip" a 3rd party type with a collection expression. But somehow it doesn't work:

IReadOnlySet<int> s = [1, 2];
Console.Write(s.Count);

[CollectionBuilder(typeof(Extensions), nameof(Extensions.Create))]
public static class Extensions
{
    extension<T>(IReadOnlySet<T>)
    {
        public IReadOnlySet<T> Create(ReadOnlySpan<T> items)
        {
            return new HashSet<T>();
        }
    }
}

With error:

Error CS9174 : Cannot initialize type 'IReadOnlySet' with a collection expression because the type is not constructible.

Given that this code is lowered to:

[Extension]
[CollectionBuilder(typeof (Extensions), "Create")]
public static class Extensions
{
  [Extension]
  [SpecialName]
  [return: Nullable(new byte[] {1, 0})]
  public static IReadOnlySet<T> Create<T>([In] this IReadOnlySet<T> obj0, [Nullable(new byte[] {0, 1})] ReadOnlySpan<T> items)
  {
    return (IReadOnlySet<T>) new HashSet<T>();
  }

  [NullableContext(1)]
  public sealed class <>E__0<[Nullable(2)] T>
  {
    [CompilerGenerated]
    [SpecialName]
    private static void <Extension>$([In] IReadOnlySet<T> obj0)
    {
    }

    public IReadOnlySet<T> Create([Nullable(new byte[] {0, 1})] ReadOnlySpan<T> items)
    {
      throw null;
    }
  }
}

It does seem like it should work - do I miss something here?

[jnm2]

There are no extension attributes. Without the original type author (in this case, the .NET runtime) applying [CollectionBuilder] on the IReadOnlySet<T> declaration itself, there is no way to add support for collection expressions to target IReadOnlySet<T>.

[HaloFour]

That's a really interesting use case for extensions. Unfortunately I don't think it could be supported without language changes to collection/dictionary expressions themselves. The compiler only knows to look at the target type itself for attributes indicating a factory method. The attributes on the Extensions class aren't related to the receiver type of the extension members or to those extension members themselves.

One suggestion might be to change collection expressions so that if the target type doesn't have CollectionBuilderAttribute, that the compiler looks for static Create methods that have some other attribute on them indicating that they would be a suitable factory method to create that collection type?

[StrawbrryFlurry]

I love C# and there are not a lot of things that I miss in my day to day live. One thing I always thought was a bummer though is how the compiler struggles when inferring constraints with more than one type argument. The main place I ususally run into this "issue" is when writing extension methods like this:

public interface ISubjectAssertion<TSubject> {
  public TSubject Subject { get; }
}

public sealed class ExceptionAssertion : ISubjectAssertion<Exception> {
  public required Exception Subject { get; init; }
  public ExceptionAssertion HasMessage(string message) => this;
}

public static class AssertionExtensions {
  public static TAssertion Match<TAssertion, TSubject>(
    this TAssertion assertion,
    Func<TSubject, bool> predicate
  ) where TAssertion : ISubjectAssertion<TSubject> {
    // ...
    return assertion;
  }
}

Here, when trying to call Match, the compiler isn't able to infer the type arguments for the method, despite all the information seemingly being available at the callsite.

var assertion = new ExceptionAssertion { Subject = new Exception("Oh no! :(") };
assertion.Match(subject => subject is InvalidOperationException);

The type arguments for method 'AssertionExtensions.Match<TAssertion, TSubject>(TAssertion, Func<TSubject, bool>)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

Of course you could just drop the type parameter for TAssertion and settle for ISubjectAssertion<TSubject> as the return type. This however strips away the original type information and we would no longer be able to call ExceptionAssertion.HasMessage on the result.

What I would love for the "extensions" feature is being able to specify "complex" constraints on the extension delcaration like:

public static class AssertionExtensions {
  extension<TAssertion, TSubject>(TAssertion assertion) where TAssertion : ISubjectAssertion<TSubject> {
    public TAssertion Match(Func<TSubject, bool> predicate) {
      // ...
      return assertion;
    } 
  }

Right now, specifying more type arguments like this doesn't seem to be possible (although I might be missing something).

Thank you for the amazing job you're doing with the language! 💖

[StrawbrryFlurry]

@jnm2

Where do write them in the syntax when you go to use a property?

Gotcha! You would likely need to enforce that the type parameter be used in either the receiver type or it's type constraint. That way the compiler should always have all the required type information when any extension member is invoked from it's receiver type.
e.g.

extension<A, B, C>(A a) where A : ISomething<B, C>
{
    public int Prop => ...;
}

This would require improving the compiler's inference capability to pick apart the constructed receiver type into the separate type arguments.

As for the invocation bit, since the compiler would need to emit a method for the property at the end, you could add back the type parameters to that getter/setter method.

var t = default(Something<int, string>);
t.get_Prop<Something<int, string>, int, string>();

[HaloFour]

I think it would be really interesting if extensions could be declared within a generic container, perhaps limited such that there could only be a single generic type parameter of the receiver type itself. That could enable future extensions to be declared that use inference of the receiver independently of inference of the other parameters. I imagine that would complicate resolution of the extension members since it would require two-pass inference, and while it doesn't technically create a hybrid third form of extensions it might encourage the ecosystem to split.

public static class FooExtensions<T> where T : IFoo {
    extension (T foo) {
        public void M<T2>(T2 arg) where T2 : IBar { ... }
    }
}

// usage
Foo foo = ...;
Bar bar = ...;

foo.M(bar);
// or
foo.M<Bar>(bar);

// lowers to
FooExtensions<Foo>.M<Bar>(foo, bar);

Doesn't solve the partial inference for properties, tho.

[StrawbrryFlurry]

I think it would be really interesting if extensions could be declared within a generic container

This could be super useful, but for a completely different use case than what I originally was asking for :D Having to only "partially" specify type parameters for methods where the receiver type is already inferred would be great for the places where you want to pass a type as a type parameter (in DI registration for example), but would ordinarily have to specify a known type as well.

If this were to be a thing, I would probably prefer the extension block being a type declaration in itself rather than being part of any existing class. That way it would be clear where type parameters belong to. This would still be more or less compatible with the current extension method model with the main difference being that we allow generic types on the "extension" declration and not on class declarations containing an extension method.

public extension FooExtensions<T, T1>(T receiver) where T : IFoo<T1> {
  public void M<T2>(T2 arg) where T2 : IBar { ... }
  public string P => receiver.SomeString;
}

Foo foo = ...;
Bar bar = ...;

foo.M(bar);
_ = foo.P;

// would lower to

public static class FooExtensions<T, T1> where T : IFoo<T1> {
  public static void M<T2>(T receiver, T2 arg) where T2 : IBar { ... }
  public static string get_P(T receiver) => receiver.SomeString;
}

FooExtensions<Foo, Baz>.M<Bar>(foo, bar);
_ = FooExtensions<Foo, Baz>.get_P(foo);

[HaloFour]

It wouldn't be compatible with existing generic extension methods, though, as the container type is never generic.

Also, I don't see where the inference of Baz would come from in either of those calls. That kind of inference isn't supported anywhere in C# today, let alone extensions.

[StrawbrryFlurry]

You're right, the way the method is called would be different from current extension methods if the receiver type were generic on the declaration level. If you wanted to support something like this though, you would need a different place than the method declaration itself to place the type parameter, no matter if you make the static container class generic like you suggested or have a separate declaration kind that translates into a generic container class.

As for inferring Baz, this is absolutely not supported as of now. It should however be possible for the compiler to piece together what the constructed receiver type is made up of and apply those pieces on the method invocation based on whatever constraint it has. This could get very complex in some scenarios, but even allowing "simple" cases like this for now would be a huge improvement over what we have right now.

foo: Foo
Foo: IFoo<Baz>
receiver: IFoo<T1?>
T1: Baz

[Hawkynt]

Maybe its just me but I always name my instance parameter @this for extensions because seeing the extension methods as an addon to the extended class, it should read similar. So when we just go on and use the normal this keyword for the captured instance, we can handle static and instance extensions with the same ONE syntax:

public static class ListExtensions
{
    extension(List<T>) 
    {
        public IEnumerable<int> WhereGreaterThan(int threshold)
            => this.Where(x => x > threshold);

        public bool IsEmpty
            => !this.Any();

        public static List<T> Create()
           => [];
    }
}

I would also prefer the mentioned syntax where 'class'-keyword gets replaced with 'extension' so the innerblock could be avoided completely:

public static extension ListExtensions(List<T>)
{
        public IEnumerable<int> WhereGreaterThan(int threshold)
            => this.Where(x => x > threshold);

        public bool IsEmpty
            => !this.Any();

        public static List<T> Create()
           => [];
}

[dotlogix]

I would also prefer the mentioned syntax where 'class'-keyword gets replaced with 'extension' so the innerblock could be avoided completely:

Sorry for the confusion I caused, I am talking about this part. I suggested nearly the same comment earlier and this would cause issues when you implement extensions on multiple different source "this" parameters.

See my suggestion here:
#8696 (comment)

[HaloFour]

It's an unfortunate aspect of the UX of Github discussions, so much context gets lost behind that "Load more ..." link that gets buried in the middle. It would be nice if they could also show how many comments/threads there are in total and provide a button to load all of them right at the beginning of the discussion.

[CyrusNajmabadi]

To address the concern about "100% compatibility," I believe that making this change could be done without breaking anything, as it doesn’t interfere with how extensions are applied or existing syntax due to the use of extension instead of class

We want the new extension system to be a drop in replacement for the old one. So it's critical that it have the semantics and emit strategy as classic extension methods. Otherwise, moving to modern extension methods could break existing consumers.

That's what the concern is when "100% compatibility" is discussed.

[CyrusNajmabadi]

is intended to make the code feel more natural and in line with the existing language patterns

As mentioned, this is something we have considered adding for a future language version.

Syntactic conveniences are things we are interested in. It's just not critical for c#14, so we would do it in a future release.

[nvmkpk]

Hope that future is not too far. It will make it look closer to the type extensions that was demoed sometime back. Also, it will reduce the indentation level necessary for the code (like how file scoped namespace did).

[2A5F]

Proposal: Duck typing invocable #9314

[wherewhere]

The document of extension is all broken.

    /// <summary>
    /// Converts <see cref="SyncCommand"/> values to their binary representation and vice versa.
    /// </summary>
    public static class SyncCommandConverter
    {
        /// <summary>
        /// The extension for the <see cref="SyncCommand"/> enum.
        /// </summary>
        extension(SyncCommand command)
        {
            /// <summary>
            /// Gets the byte array that represents the <see cref="SyncCommand"/>.
            /// </summary>
            /// <param name="command">The <see cref="SyncCommand"/> to convert.</param>
            /// <returns>A byte array that represents the <see cref="SyncCommand"/>.</returns>
            public byte[] GetBytes() { ... }

            /// <summary>
            /// Returns an enumerator that iterates through the <see cref="GetBytes(SyncCommand)"/>.
            /// </summary>
            /// <param name="command">The <see cref="SyncCommand"/> to get enumerator.</param>
            /// <returns>An enumerator that can be used to iterate through the <see cref="SyncCommand"/>.</returns>
            public IEnumerator<byte> GetEnumerator() { ... }

            /// <summary>
            /// Determines which <see cref="SyncCommand"/> is represented by this byte array.
            /// </summary>
            /// <param name="value">A byte array that represents a <see cref="SyncCommand"/>.</param>
            /// <returns>The corresponding <see cref="SyncCommand"/>.</returns>
            public static SyncCommand GetCommand(byte[] value) { ... }

            /// <summary>
            /// Determines which <see cref="SyncCommand"/> is represented by this byte array.
            /// </summary>
            /// <param name="value">A byte array that represents a <see cref="SyncCommand"/>.</param>
            /// <returns>The corresponding <see cref="SyncCommand"/>.</returns>
            public static SyncCommand GetCommand(ReadOnlySpan<byte> value) { ... }
        }
    }
}

Which became:

<member name="T:AdvancedSharpAdbClient.Models.SyncCommandConverter">
    <summary>
    Converts <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/> values to their binary representation and vice versa.
    </summary>
</member>
<member name="T:AdvancedSharpAdbClient.Models.SyncCommandConverter.">
    <summary>
    The extension for the <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/> enum.
    </summary>
</member>
<member name="M:AdvancedSharpAdbClient.Models.SyncCommandConverter..GetBytes">
    <summary>
    Gets the byte array that represents the <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/>.
    </summary>
    <param name="command">The <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/> to convert.</param>
    <returns>A byte array that represents the <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/>.</returns>
</member>
<member name="M:AdvancedSharpAdbClient.Models.SyncCommandConverter..GetEnumerator">
    <summary>
    Returns an enumerator that iterates through the <see cref="M:AdvancedSharpAdbClient.Models.SyncCommandConverter.GetBytes(AdvancedSharpAdbClient.Models.SyncCommand)"/>.
    </summary>
    <param name="command">The <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/> to get enumerator.</param>
    <returns>An enumerator that can be used to iterate through the <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/>.</returns>
</member>
<member name="M:AdvancedSharpAdbClient.Models.SyncCommandConverter..GetCommand(System.Byte[])">
    <summary>
    Determines which <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/> is represented by this byte array.
    </summary>
    <param name="value">A byte array that represents a <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/>.</param>
    <returns>The corresponding <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/>.</returns>
</member>
<member name="M:AdvancedSharpAdbClient.Models.SyncCommandConverter..GetCommand(System.ReadOnlySpan{System.Byte})">
    <summary>
    Determines which <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/> is represented by this byte array.
    </summary>
    <param name="value">A byte array that represents a <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/>.</param>
    <returns>The corresponding <see cref="T:AdvancedSharpAdbClient.Models.SyncCommand"/>.</returns>
</member>

The SyncCommandConverter.extension become SyncCommandConverter.. Is that normal?

[RikkiGibson]

If you are seeing an incorrect behavior in the implementation please file a bug on dotnet/roslyn. Thanks!

[nfplee]

I thought I would throw in my 2 cents. I have the following dislikes for the current proposed syntax:

• Too much indentation to actually declare the extension methods/properties.
• Parenthesis next to keyword without a space looks odd.

Here's an alternative syntax:

Extension methods/properties

public extension Extensions for IEnumerable<int> source {
    ...
}

source receiver could be optional, this would be default, or could just use this instead of source above. Also the name (Extensions above) could be optional.

Static extension methods/properties

public static extension Extensions for List<T> {
    ...
}

static keyword could possibly be used to differentiate between non-static extension methods if the receiver is optional, if not then it is not required.

Generics

public extension Extensions<T> for IEnumerable<T> source where T : INumber<T> {
    ...
}

What I like:

• Resolves the dislikes. Could optionally allow within a class.
• for IEnumerable<int> source looks similar to is IEnumerable<int> source for the existing pattern matching syntax.
• for keyword reads nicely like is and where.

[aradalvand]

which force extensions to be split across many declarations

@HaloFour That is still much better than the indentation, and it objectively involves fewer characters.
Not to mention it would also eliminate the need for any future syntactic sugar.

[HaloFour]

That is still much better than the indentation, and it objectively involves fewer characters.

No it's not. It opens entirely different cans of worms and still doesn't address the problems well. You have all kinds of receiver and generic scoping rules which make no sense to the rest of the language. Frankly, one additional level of indentation is a tiny price to pay to avoid all of that.

It's not like the team didn't spend a lot of time trying to get type-level extensions to work, either. That was where the discussion started years ago. Even without the compatibility concerns it quickly became apparently how much that form didn't work when attempting to solve for common use cases. That's when the team pivoted back to member-based syntax, which became its own verbose mess. Well before the current syntax was proposed the team was leaning towards syntax to group extensions within a container class.

[martin-steinhoefer]

It's not like the team didn't spend a lot of time trying to get type-level extensions to work, either. That was where the discussion started years ago. Even without the compatibility concerns it quickly became apparently how much that form didn't work when attempting to solve for common use cases.

Sadly enough - that's true. I would have liked to see type-level extensions come to life. However, you did a great work so far.

That's when the team pivoted back to member-based syntax, which became its own verbose mess.

Did I miss something when doing recap? I just need a hint, where to start reading... thanks in advance

[HaloFour]

It was discussed over many design meetings. The bulk of it started around September 30th and into October. There are a couple of documents exploring different syntax forms:

Compatibility thorugh coexistence between extension types and extension methods

Extensions: An evolution of extension methods

The design space for extensions

There's a lot here and it definitely is a bit difficult to keep track of, let alone summarize. An enormous amount of spaghetti has been thrown at the wall.

[martin-steinhoefer]

It was discussed over many design meetings. The bulk of it started around September 30th and into October. There are a couple of documents exploring different syntax forms:

Compatibility thorugh coexistence between extension types and extension methods

Extensions: An evolution of extension methods

The design space for extensions

There's a lot here and it definitely is a bit difficult to keep track of, let alone summarize. An enormous amount of spaghetti has been thrown at the wall.

Thank you for the information

[jaliyaudagedara]

Is this something we are considering?

To validate this:

public static class Extensions
{
    extension(IEnumerable<int> source)
    {
        public IEnumerable<int> WhereGreaterThan(int threshold)
        {
            ArgumentNullException.ThrowIfNull(source);

            return source.Where(x => x > threshold);
        }

        public bool IsEmpty()
        {
            ArgumentNullException.ThrowIfNull(source);

            return !source.Any();
        }
    }
}

Would be nice, if we can do this instead,

public static class Extensions
{
    extension(IEnumerable<int> source)
    {
        // No duplication
        ArgumentNullException.ThrowIfNull(source);

        public IEnumerable<int> WhereGreaterThan(int threshold)
            => source.Where(x => x > threshold);

        public bool IsEmpty()
            => !source.Any();
    }
}

[Hawkynt]

To feel like an instance method we would need to throw NullReferenceException

[IS4Code]

To feel like an instance method we would need to throw NullReferenceException

That's pretty much what happens if you don't add any guards against null in these implementations. In any case, throwing NullReferenceException is not a good idea, since you would still see the exception thrown in the methods themselves and therefore you might mistakenly think there is some error in the implementation. ArgumentNullException points you to the parameter immediately so you know it is a "failed pre-condition" case.

Also worth noting is that we will (I hope) have both extension(IEnumerable<int> source) and extension(IEnumerable<int>? source), which, by the language's current principles, should not have differing interpretation other than nullability warnings. Extension methods for null targets are completely viable (and useful!), so any sort of guarding against null should not happen automatically (and thus will likely be covered by another orthogonal feature).

[zms9110750]

Using the default implementation and extension members of an interface allows a class to obtain APIs in bulk in a manner similar to multiple inheritance.
Is there a way to restrict access so that a class can only obtain these APIs, as it won't receive the APIs from the interface's default implementation?
While interfaces can inherently use these APIs without any ambiguity due to identical signatures, I still feel that it adds complexity.
I recall that other languages achieve polymorphism through ownership rather than inheritance, directly obtaining APIs. However, we can only resort to this workaround.

[HaloFour]

I'm not sure I understand your question. If a type implements an interface, every member declared on that interface can be called through the interface. That includes members that aren't implemented on the type itself. That cannot be restricted because that is exactly the contract that the interface requires. As extensions cannot provide implementations, I'm not sure how that fits with this discussion.

[zms9110750]

@HaloFour

MyList<int> a = []; 
IMyList<int> b = a;

a.Contains(1);//from MyListExitend

b.Contains(1);//from IMyList
			  // i want it can't call MyListExitend

class MyList<T> : IMyList<T>
{

}
 
interface IMyList<T> : IList<T>
{
	bool ICollection<T>.Contains(T item) => IndexOf(item) > -1; 
}

static class MyListExitend
{ 
	public static bool Contains<T>(this IMyList<T> values, T item)
	{
		return values.Contains(item);
	}
} 

[HaloFour]

So your question is whether extensions can "replace" actual members that are declared on the receiver type, and the answer is no, they can't.

See: #8696 (reply in thread)

Extensions do not allow for overriding an instance method with an extension. That was true in C# 2, and remains true now. It has been feedback since the start (to the point of being a practical mandate) that ones own instance members must always take precedence statically over extensions.

[IS4Code]

that ones own instance members must always take precedence statically over extensions

Of course there is the one exception which makes Count() take precedence over Count when the latter is not a delegate.

[blowin]

Good afternoon, is it planned to extend the type by adding new interfaces?

This would:

• Improve code organization by keeping interface implementations separate from type definitions.
• Enable adding implementations to existing types without modifying their source code.
• Reduce boilerplate when working with third-party libraries or sealed classes.

Syntax:

public static class ListExtensions
{
    extension(List<T> source) : IEquatable<List<T>>
    {
        public bool Equals(List<T> other)
        {
             return !(other is null) &&
                        (ReferenceEquals(source, other) || (source.Count == other.Count && source.SequenceEqual(other)));
        }
    }
}

Benefits:

• Flexible extensibility: Add functionality to existing types (even sealed or BCL classes).
• Better Separation of Concerns: Implementations can be grouped by feature rather than by type.
• Reduced Adapter Boilerplate: Avoid wrapper classes just to satisfy interfaces.

I would appreciate it if this opportunity is considered for addition.

[HaloFour]

See this thread: #8696 (comment)

The TL;DR is that the team has expressed interest in doing something in this space, although not necessarily through extensions.

[jcouv]

Extension interfaces is something we'd love to do in some fashion, but it's not clear that there's a solution to the many constraints, so some trade-offs are likely necessary.
The desideratas: to achieve identity (instances of C and CExtendedWithI, and D<C> and D<CExtendedWithI>) even with existing generic IL already in the wild, while keeping type safety, allowing different extensions to add different interfaces and keeping the whole thing efficient...
Here's a good write-up: #7928

[sab39]

Have we definitely lost the for keyword that was part of the syntax in some of the earlier proposals? I always thought it was a particularly nice touch to take advantage of a true, reserved, non-contextual keyword that already exists in the language, whose meaning in English is a perfect fit for this use case. Is the current syntax without for pretty much settled (other than the plan to add shorthand forms in future)? Is there something in meeting minutes about the choice to move away from that part of the proposal?

[HaloFour]

There were forms of grouping syntax that also included a for keyword at one point in time. I think it simply became unnecessary when the syntax moved towards an extension clause and primary-constructor-like receiver argument. I kind of expect it will remain unnecessary even with shorthand forms, although I don't think any real design discussion has happened there.

[timcassell]

It might come back for roles. (Or roles could use a similar syntax as extensions, who knows?)

[MichaelMcGlothlin]

Adding support for extension properties is a good idea. The rest of this is just needlessly complicating the language for minimal benefit.

[kyoyama-kazusa]

I don't know whether this is a correct behavior or not:

using System;

int integer = 42;
integer.Method("hello"); // okay
integer.Method<string>("hello"); // not okay
integer.Method<int, string>("hello"); // okay

file static partial class Program
{
    extension<T1>(T1 instance)
    {
        public void Method<T2>(T2 another)
        {
            Console.WriteLine((instance, another).ToString());
        }
    }
}

It seems that I should explicitly specify all two type parameters to make compiler happy... Is it by-design?

[HaloFour]

I honestly like the idea of allowing for the extension container to be generic:

public static class ListExtensions<T> {
    extension (List<T> list) {
        public void DoSomething<U>() { }
    }
}

// given
List<int> list = new List<int>();
// usage
list.DoSomething<Foo>();
// lowers to
ListExtensions<int>.DoSomething<Foo>(list);

Then it's just a new feature that can be used by both new and existing extensions rather than some kind of compat-specific feature.

[CyrusNajmabadi]

I like that idea too. Def worth looking into :)

[nathan130200]

We cannot implement custom implicit conversion using extensions members, would be interesting too.

[CyrusNajmabadi]

I believe, but would have to check, that custom conversions are something we want to support.

[Kuurama]

Extension containers as generics looks great!