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.

[danwallentin]

Invokable objects — a case for more expressive object-oriented code

I'd like to revisit the idea of supporting invokable objects in C#, similar to C++'s "operator()".

I believe this would be a valuable addition to C#, not merely as syntactic sugar, but as a way to improve expressiveness, readability, and domain modeling.

The problem

Consider classes named "SignIn", "Signal", or "Transform". These names naturally describe both an object and an operation.

Today, we often end up writing code such as:

var signIn = new SignIn(authenticator);
var result = signIn.Execute(credentials);

Or even:

var result = signIn.SignIn(credentials);

The method name often adds no meaningful information. We introduce names like "Execute", "Invoke", "Handle", or "Process" simply because the language requires an explicit method call.

Ideally, we could write:

var signIn = new SignIn(authenticator);
var result = signIn(credentials);

With a corresponding declaration such as:

public class SignIn
{
public Result operator()(Credentials credentials)
{
// ...
}
}

A more expressive example: Transform

Consider a transformation object that encapsulates a matrix:

public class Transform
{
private readonly Matrix _matrix;

public Transform(Matrix matrix)
{
    _matrix = matrix;
}

public Vector operator()(Vector vector)
{
    return _matrix * vector;
}

}

We could then write:

var rotate = new Transform(rotationMatrix);
var scale = new Transform(scaleMatrix);

var result = scale(rotate(vector));

Compare that with today's C#:

var result = scale.Apply(rotate.Apply(vector));

The former reads almost like mathematical notation, while still benefiting from encapsulation, strong typing, and compile-time checking.

Another natural example would be a signal:

var signal = new Signal(frequency, amplitude);
var value = signal(time);

This closely resembles the mathematical expression "s(t)".

Why not just use static methods or delegates?

Static methods cannot naturally encapsulate per-instance state and dependencies.

Delegates can provide invocation syntax, but they do not offer the same direct object-oriented modeling experience as a named, callable class with its own state, identity, and additional members.

Invokable objects would combine both worlds: the expressiveness of function invocation and the encapsulation of ordinary objects.

Implementation considerations

This should not require changes to the CLR or .NET runtime.

The C# compiler could translate the invocation operator into an ordinary instance method in IL, just as it does for other operators.

Of course, language design questions such as overload resolution, generics, and compatibility would need to be addressed. But the underlying concept is well established in C++.

Closing thoughts

I believe invokable objects would be particularly valuable in object-oriented code, where the name of an object often already expresses its primary behavior.

Good abstractions should minimize unnecessary ceremony. Sometimes the most readable API is one where the abstraction almost disappears at the call site.

I'd love to see this feature reconsidered.

[CyrusNajmabadi]

Can you please fix your formatting @danwallentin

I also don't understand this:

Delegates can provide invocation syntax, but they do not offer the same direct object-oriented modeling experience as a named, callable class with its own state, identity, and additional members.

They absolutely can do this. It is totally reasonable to expose the named (or even unnamed) functionality of a class through a delegate you invoke.

The request lacks reasoning for why to couple these. Instead of leaving them decoupled.