Proposal: Add `invokeable?(...)` as short hand for `invokeable?.Invoke(...)` and add support for any "invoke-able" type

[nietras]

Proposal: Add invokeable?(...) as short hand for invokeable?.Invoke(...) and add support for any "invoke-able" type

It is proposed to extend and generalize the delegate(...) invocation operator to reduce the amount of repetitive code and support new scenarios for succinct invocation of types following a specific pattern. Such a type is referred to as an "invoke-able" type in this proposal and is any type having any method called Invoke or types made invoke-able via extension methods. Hence, C# should use structural matching for the invokeable(...) and invokeable?(...) invocation operator and not match on whether a type is a delegate.

There are two parts to the proposal:

• Allow invocation to support the null-propagation operator i.e. action?()
• Extend invocation () to structurally match any type with one or more Invoke methods available incl. generic methods and extension methods, perhaps even static types.

See Member access operators for existing operators.

In this proposal examples are in C# 8 with nullable enabled.

Motivation

A common and easy pattern to use for logging is to simply use/inject a delegate Action<string>. Allowing this to be null with the meaning that logging is disabled. This is simple to implement and has low coupling. But is also a bit tedious currently in C#:

public void M(Action<string>? log) => log?.Invoke("test");

compared to how this is if this couldn't be null:

public void M(Action<string> log) => log("test");

Proposed Solution

Hence, the first part proposes changing this to allow the null-propagation operator for invocation. It already exists for methods ?. and indexers ?[] and it seems natural to extend that so the following is allowed and is simply a short hand for ?.Invoke(...). With null-propagation being exactly the same. delegate() just emits delegate.Invoke() in IL so this does not change generated code.

public void M(Action<string>? log) => log?("test"); // log?.Invoke()

Other examples:

public int? M(Func<int>? get) => get?(); // get?.Invoke()
public string? M(Func<string>? get) => get?(); // get?.Invoke()

Similar Patterns

Below are examples of existing null-propagation for comparison.

public int? M(int[][][] values) => values?[2]?[1]?[0];
public int? M(Foo? foo) => foo?.Bar?.M();

Extended Solution

Since, the invocation operator () for delegates is simply a short hand for .Invoke(), it is also proposed to extend the invocation operator () for any scenario where a type or instance has any method called Invoke available. Whether it be a member method or an extension method. This helps a lot in patterns that define first class invoke-able types. Hence, the invocation operator should be available as soon as the compiler can find a structural match. Examples are given in the two sub-sections.

In fact, this could also be extended to static classes with static methods called Invoke. One could simply invoke this directly. This is up for discussion and not part of the main proposal here. Example can be seen below.

public static class Foo { public static int Invoke() => 42; }
public int M() => Foo(); // Foo.Invoke();

what benefit would there be to this... don't have any good examples now which is also why this is not part of main proposal.

Member method example

public interface IFunc<TResult> { TResult Invoke(); }
public int M<TFunc>(TFunc compute) where TFunc : IFunc<int> => 
    compute(); // compute.Invoke();
public int? M<TFunc>(TFunc compute) where TFunc : IFunc<int> => 
    compute?(); // compute?.Invoke();

the above example is a pattern I have used a lot for numerical libraries where one need to apply a "functor" to each element in an "array". By defining a value type TFunc one can get method inlining which is cruzial for performance. The desire is code generated specifically for that TFunc. Trading code size for performance. Often this involves unrolling loops and hence a lot of .Invoke( in the code. This is just an example and the main point is this gets more succinct with the invocation operator being available for the types involved. Performance will not change in any way for this proposal. IL is the same.

Extension method example

public struct Foo { public int Test() => 42; }
public static class FooExtensions { 
    public static int Invoke(this Foo foo) => foo.Test(); 
}
public class Bar { 
    public int M(Foo foo) => foo(); // foo.Invoke();
    public int? M(Foo? foo) => foo?(); // foo?.Invoke();
}

Above shows how this would also work for extension methods.

Future

In the future C# might get static delegates, traits and hopefully many other things. By extending the invocation operator and adding null-propagation invocation operator these will make it natural to invoke any type or instance that is invoke-able. Hence, Action<> and Func<> like types get easy to use invocation operator support.

There already is a proposal to extend using to be based on structural matching, which makes a lot of sense in the face of ref-types. cc: @gafter
#1623

Generally, I think it would be preferable to direct C# towards being based more on "patterns" rather than exact type matching, since that creates a direct coupling between runtime types and language. When possible this would make C# more "free" and open to other use cases. Letting new code patterns could emerge.

[jnm2]

Overlaps or duplicates #95

[nietras]

overlaps or duplicates #95

Searched and searched but didn't search for "functor" 🤦‍♂️😅

[Joe4evr]

log?("test")

I have a feeling the parser isn't going to like this, since while the statement is still incomplete, it'll have to guess between "is this a null-safe invoke of an invokable?" and "is this an unfinished conditional expression (condition?(true-branch))?". The IDE experience would be terrible if it's ambiguous all the time.

[iam3yal]

We can also go with a slightly different syntax like foo:() and foo:?() to indicate that we make a call to function object as opposed to a method, just an idea.

[CyrusNajmabadi]

THe former is already legal. i.e. x ? foo : (...) ...

[iam3yal]

@CyrusNajmabadi True, maybe something similar, dunno.

[nietras]

Overlaps or duplicates #95

Well doesn't duplicate 100% so keeping this open, since I think both null-coalescing operator and extending the usage ties together. Which brings me to null-coalescing operator issues.

parser isn't going to like this, since while the statement is still incomplete, it'll have to guess between "is this a null-safe invoke of an invokable?" and "is this an unfinished conditional expression (condition?(true-branch))?". The IDE experience would be terrible if it's ambiguous all the time.

In what cases would this be ambiguous? The type of the condition/expression before ? should be determinable and hence the compiler/intellisense can selectively show what fits this. Not unlike what already happens in existing null-coalescing scenarios. Or when a user write ( after a ?, it has to be determined what was the type of the statement before ? and then suggest based on that, if that is not determinable/easy or whatever, current behavior is to show nothing. So I don't see a major issue here. This can all be handled.

One interesting case would be what happens in the face of implicit conversions. E.g. given a type:

public struct FooBoolean
{
    public bool Value => false;
    public int Invoke() => 42;
    public static implicit operator bool(FooBoolean foo) => foo.Value;
}

this does not work currently if foo is nullable:

    public int? N(FooBoolean? foo) => foo ? (42) : 16;

it fails with the following error:

It works fine when foo is not null of course:

    public int? N(FooBoolean foo) => foo ? (42) : 16;

But in neither case is there any intellisense help or suggestions when writing ?(. And if null-coalescing invocation operator is added it should be easy enough to determine whether foo is invokeable and whether foo is implicitly convert-able to a bool. One could then err on the conservative side and not show any completion for ( when an implicit conversion to bool exists.

Hence, overall I don't see an issue here. :)

[gafter]

The type of the condition/expression before ? should be determinable and hence the compiler/intellisense can selectively show what fits this.

No, types are not known in the parser. Parsing determines the syntactic structure of the expression before its types can be determined.

[nietras]

No, types are not known in the parser. Parsing determines the syntactic structure of the expression before its types can be determined.

Does that mean that you think parsing ?( as something other than ? () : ; is not possible? Hence, ?( is forever bound to the ternary operator?

[YairHalberstadt]

At the syntax level, foo?(bar)?(bar) : null is ambiguous between foo?.Invoke(bar) ? bar : null and foo ? bar?.Invoke(bar) : null so I think this is genuinely impossible to parse.

[nietras]

Yes I can see that it is definitely not easy at parser only level :) Alright, feel free to close this PR if null-coalescing invocation operator is deemed impossible. The other part of this proposal seems to be already covered.

[AartBluestoke]

@gafter isn't that just an operator precedence issue? we don't complain about many other issues where the syntax has alternate interpretations depending on the implied brackets:
foo?(bar)?(bar) : null would always either equal (foo?(bar))?(bar) : null or foo?((bar)?(bar)) : null depending on the precedence of nullable-invoke vs terniary if. If it is the first, then it is "easy" to parse: if the next ternary location contains a "?" then you previously had an invoke, and that one is the next one to consider, else have a ":" and that first "?" was a terniary.

[YairHalberstadt]

depending on the precedence of nullable-invoke vs terniary if.

I don't think this is true. Precedence tells me, once I've parsed the operators, where do I put the brackets. Here we don't even know how to parse the operators.

[AartBluestoke]

i don't see that it is impossible to parse?

Given

 a is a string of alphanumeric chars (a name-of-a-thing, can't think of the precise language name for this)
 b is the next chunk of text out to the matched bracket (typically 0..n comma separated expressions)
 c is the rest of the expression.

then to parse the following expression:
a?(b)c
if c begins with ":" then the ? was a ternary, and b was an expression, else it is a nullable function call and b was a parameter list.
(some condition, else it was a syntax error)