Champion "Extension function members"

[gafter]

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

See also dotnet/roslyn#11159

[Thaina]

Almost agree and totally support with a bit of arguments and concerns

• Name of this feature make it not sure if this will be able to extend field or not, I would disagree to extend fields

• Extension struct should always pass by reference. Same behaviour as normal implementation of struct. This solve the problem of passing struct by ref for extension method altogether

• How can we find duplicate operator? When it cause function conflict error it will be hard to find, unlike named member that could go to reference

• Would this syntax will be able to extend enum ?

• Is this include extension to implement interface ?

• We don't need new keyword extension if we could permit static class to extend anything. Reusing keyword and it already intuitive to have static class hold extension method

/// static class cannot extend anything before so it not breaking any previous code
public static class Ext : MyStruct
{
}

[Bartmax]

I think I'm late to the party and forgive my ignorance, but what about just supporting partial keyword for non-partial classes ?

[orthoxerox]

@Bartmax partial is for classes in the same assembly. It simply combines several pieces of the same type during compilation. Extensions are for extending arbitrary classes, including those from external compiled assemblies.

[Bartmax]

i know that, but that doesn't mean it can be "reworked" to allow classes from other assemblies hence creating extensions for arbitrary classes.

[alrz]

I'd suggest the following syntax for extension declarations,

internal extension [class] StringExtensions for String { }
internal extension [class] GenericExtensions<T> for T where T : class { }

I believe the name should be optional for convenience (e.g. private nested extension declarations don't really need to be named):

private extension [for] String { }
private extension<T> [for] T where T : class { }

Similarly, instead of base list, we could use implement to plug interface/shape/traits to types,

implement TraitT for String { }
implement<T> FooT for T where T : BarT { }

This has various advantages like segregating impls so that they do not show up on all instances. Explicit implementations could have the same effect in extension declarations, but I think it's good to separate these concerns (auxiliary methods vs trait implementations).

Please consider this feature for the nearest releases. It would make life so much easier.