Strawman proposal: Invokable objects (and faking two-phase lookup)

[sab39]

Rationale

Thinking about two-phase lookup in the context of extensions, it occurred to me that we might be able to fake it (at least for the most basic cases) with a variation on the same trick we've used since the inception of C# for faking named indexers.

The simplest version of the problem scenario in extensions looks something like:

extension<T1>(T1 receiver)
{
   public void DoThing<T2>() { ... }
}

People would like to be able to call this as obj.DoThing<SomeType>(), where SomeType is T2, and T1 is inferred as the static type of obj. Today this doesn't work and you have to say obj.DoThing<ObjType, SomeType>() instead, which is counterintuitive and loses the benefit of inference.

My thought is that we could fake the desired behavior, much like we fake named indexers today. C# doesn't support named indexers (obj.Stuff[...]) directly, only default indexers (obj[...]). But if we make a property called Stuff that returns a second type, and that type has a default indexer, then as far as consuming code is concerned, it looks and quacks an awful lot like a named indexer.

In the same way Stuff is a property whose type behaves like an indexer, we'd make DoThing a property whose type behaves like a generic method group. That's not possible today, of course, but it occurred to me that we could make it possible with a fairly small and self-contained change to the language. Specifically, we could give DoThing's type an Invoke<T2> method, and implicitly lower obj.DoThing<SomeType>() to obj.DoThing.Invoke<SomeType>().

Note that it would still be up to the extension developer to implement the fakery; I'm definitely not suggesting that extensions would lower into this form automatically. Again, this mirrors the way named indexers are done.

After overthinking that idea for a while, here's what I ended up with.

Detailed proposal

If an expression expr resolves to a value of type F, and F is a non-delegate type with at least one accessible instance or extension method named Invoke, then:

• expr( args ) is equivalent to expr.Invoke( args ), including any inference of generic parameters that would be applied in the full form.
• expr< TypeArgs >( args ) is equivalent to expr.Invoke< TypeArgs >( args ).
• expr can be target-typed or implicitly converted to any delegate type if the expression expr.Invoke could be, with the same result, including generic inference.
• expr< TypeArgs > is allowed and can be target-typed or implicitly converted to any delegate type if expr.Invoke< TypeArgs > could be, with the same result. It doesn't have a natural type, even if the expanded form would be naturally typed as a Func or Action.

Considerations

• Limiting to instance methods avoids ambiguity of Foo<T>() between static methods Foo<T>.Invoke() and Foo.Invoke<T>(). Of course we could specify rules for resolving such things, but I don't see any real benefit that would outweigh the complexity and potential confusion.
• Any user-defined conversion operators on F would need to take precedence over this new implicit conversion, to avoid a breaking behavior change for code that is legal today.
• We could exclude extension Invoke methods from this behavior, but that seems overly limiting when we're actively trying to expand the kinds of member that extensions can provide, so my proposal permits them.
• As far as I can tell, none of these syntax forms are ambiguous with any generic code constructs that are legal today.
  • The trickiest corner case I can think of would be if a type Thing<T> and a property Thing with an instance Invoke<T> method were both in scope, making the expression Thing<T> potentially ambiguous, but I think it's still okay:
  • Thing<T>( is currently illegal in existing code and would always refer to the method (except after new)
  • Thing<T>. would always refer to static members of the type; the new conversion can never apply in a situation that would be immediately followed by a .. (This assumes the new conversion wouldn't be applied to receivers of extension methods, but I believe that's already the case for all implicit conversions anyway)
  • In almost all other cases only a type or a value is syntactically valid so there's only one possible interpretation.
  • The only place I can think of that allows both is nameof() which would never apply the new conversion anyway.
• I'm not completely confident about it, but I don't think this adds any ambiguity with legal code using < and > as comparison operators. Hopefully the same rules that distinguish type parameters from comparison operators today can handle it.
• To reduce the scope of possible impact to existing code, we could limit this behavior to types or methods that explicitly opt in with an attribute.
• We could go even further (although this seems overkill to me) and mirror the way indexers are treated in the language, allowing public void this() { ... } to lower to an Invoke method that's hidden from the language, as the name Item is hidden for indexers today.

[HaloFour]

I'm personally not a fan of how generics are proposed to work with this. It definitely feels like it exists very specifically to try to workaround the generic arity issue with generic methods but doesn't make a whole lot of sense on its own.

[sab39]

I could say that "it's well tailored to its main motivating scenario" sounds like a feature rather than a bug 😉. Snark aside, I do see where you're coming from. I'd offer a couple of counterpoints:

1. Judging by how common a topic it is on the extensions discussion thread, the arity issue with generics in extensions is a significant pain point for a lot of people, but the ideal solution involves a broader scope and major effort. Seems to me that if a relatively small and inoffensive change can reduce that pain in the short term, it's worth considering.

2. The proposal is only applicable when we know for certain that method-like or delegate-like behavior is intended, either because the expression is being directly invoked (expr<T>(...)), or because it's being target typed or converted to a delegate type. (Intellisense already has this context: with a val in scope, list.Add(v<space> autocompletes to val, but list.Select(v<space> doesn't, to allow v => ...). In general, I completely agree that it'd be surprising and nonsensical for expr<T> to refer to an Invoke method. The rule that it has no natural type was meant to enforce this, but the wording should probably be changed to outright disallow it.

3. I think it's overstating things to claim it doesn't make sense outside the context of generic arity - there are other use cases, albeit by no means common enough or compelling enough to motivate the feature by themselves. It's not unusual to have an object that represents some kind of operation; methods with names like Call and Invoke show up all over the place (and at least occasionally take generic parameters). C# has always let types support syntax features associated with what they represent: indexers allow array-like syntax, Deconstruct for tuple syntax, GetEnumerator and GetAwaiter for await and foreach, operators for number-like arithmetic, and so on. Providing a pattern for an object to support being invoked like a method or method group seems well within the same spirit, but isn't possible today: the only way to be callable is to actually be a delegate.