[Proposal]: Extension members on typeless receivers

[CyrusNajmabadi]

Extension members on typeless receivers

• Specification: proposals/extension-members-on-typeless-receivers.md
• Champion issue: [Proposal]: Extension members on typeless receivers #10146

Summary

Allow extension members to be invoked on a receiver expression that has no type:

// All errors today.
var a = [1, 2, 3].ToImmutableArray();
var memoized = SomeMethod.Memoize();
var x = (cond ? null : GetInt()).SomeNullableExtension();

Resolution treats the receiver as the first argument of each candidate extension member, then picks the best applicable candidate by the existing overload-resolution rules. Receivers that already have a type bind by the existing rules, unchanged.

Design meetings

This proposal has not yet been reviewed by LDM. Prior LDM and working-group discussions that inform the design:

• LDM 2023-07-12. Identified "allow extension methods on expressions with no natural type" as a separate orthogonal track to the collection-expressions-only ergonomic.
• Collection literals working group, 2023-06-26. The [complex, type, examples].AsImmutableArray() motivating scenario, with the broader claim that null, lambda, and method-group receivers should also participate.
• Collection literals working group, 2024-01-23. Concrete (x => true).ExtensionOnStringPredicate() example and explicit framing of the feature as extension methods on target-typed constructs.

[TonyValenti]

I want this so bad.

[bzd3y]

This would be great. I ran into this the other day and was disappointed/surprised that it didn't work for something like [1, 2, 3].ToImmutableArray();.

[CreateAndInject]

Does this contain immediately-enumerated-collection-expressions?

[CyrusNajmabadi]

No. Those are separate cases.