Proposal: Language support for Func & Action

[TylerBrinkley]

Similar to what was done for ValueTuple in roslyn#347, Func and Action should be given language support in order to support naming parameters as well as making them more user friendly, especially for new .NET developers who are less acquainted with them. Named parameters can currently be specified when creating custom delegates but doing so is discouraged as they aren't assignable to the ubiquitous Func and Action. The table below shows what this feature might look like.

Before	After
Action	(() => void)
Action<decimal>	((decimal amount) => void)
Action<int, string>	((int index, string value) => void)
Func<DateTime>	(() => DateTime)
Func<DateTime, int>	((DateTime startDate) => int)
Func<int, int, int>	((int inclusiveMin, int exclusiveMax) => int)

The great thing about this is that existing API's can be updated to provide better documentation of the input parameters of these delegates without breaking compatibility.

Syntax

The general syntax is ((inputParameters) => returnType) where inputParameters are a comma separated list of the input parameters or empty when there are no input parameters.

Enclosing parentheses are required

Enclosing parentheses are required to distinguish the alias as a type.

Arrow

The arrow => separates the input parameters from the return type. It was chosen as it mirrors lambda and expression bodied members syntax.

No input parameters syntax

The syntax for no input parameters is a set of empty parentheses, (). The set of empty parentheses was chosen as it mirrors lambda's syntax for no input parameters.

No return parameter syntax

The syntax for no return parameter, e.g. Action delegates, is void as this mirrors the existing method syntax.

Parameter names

The parameter names are optional and would only be stored at API surface levels in an Attribute similar to how tuples work.

Alias syntax within methods

Additionally this syntax could also be used within methods to declare variables so the following

Func<int, string> stringifier = a => a.ToString();

could become

((int value) => string) stringifier = a => a.ToString();

Existing BCL Use Cases

To show how ubiquitous Func and Action are in the BCL, when going through the preliminary .NET Standard 2.0 spec there was found around 544 references to Func and around 121 references to Action.

LINQ uses Func so all of those methods would benefit.

Factory parameters would also benefit such as those in ConcurrentDictionary's AddOrUpdate method which would go from this

public TValue AddOrUpdate(
    TKey key,
    Func<TKey, TValue> addValueFactory,
    Func<TKey, TValue, TValue> updateValueFactory);

to this

public TValue AddOrUpdate(
    TKey key,
    ((TKey key) => TValue) addValueFactory,
    ((TKey key, TValue existingValue) => TValue) updateValueFactory);

Named parameter support

Invoking Funcs and Actions using named parameters should be supported such that what is now this

Func<double, double, double> bmiCalculator = (w, h) => w / h / h * 703;
var bmi = bmiCalculator(123, 64);

can now become the following which improves readability.

((double weight, double height) => double) bmiCalculator = (w, h) => w / h / h * 703;
var bmi = bmiCalculator(weight: 123, height: 64);

Using Invoke explicitly such as with the null propagation operator should also support named parameters.

Optional / Default parameter support

Support for optional / default parameters should be considered through use of attributes at API boundaries. Below is an example that might be considered.

((double weight, double height, bool isMetric = false) => double) bmiCalculator = (w, h, isMetric) => w / h / h * (isMetric ? 1 : 703);
var bmi = bmiCalculator(123, 64);

Params parameter support

Support for params parameters should be considered through use of attributes at API boundaries. Below is an example that might be considered.

((string separator, params string[] items) => string) joiner = string.Join;
var str = joiner(" ", "a", "b", "c");

Open Questions

• Should there be an optional simplified syntax for when there is only one input parameter to not require the surrounding parentheses, similar to lambda syntax? If so should it only apply when there is no parameter name associated with the parameter such as (int => string) or should it also apply when there is a parameter name such as (int value => string)?

Updates

• Added support for multiple return values through Tuples.
• Added mention of custom delegates supporting named parameters.
• Changed the empty input parameters case to include just empty parentheses and the empty return parameter to void.
• Added existing BCL use cases section.
• Removed support for multiple return parameters.
• Removed support for a named return parameter.
• Removed out and ref parameters consideration.
• Added named, optional, and params parameter support for consideration.
• Switched to requiring parentheses around all input parameters.
• Added open question about whether to support a simplified syntax for when there is only one input parameter.

[gulshan]

Have you tried expression bodied local functions? For quick comparison-

Func<int, string> func = a => a.ToString();  // lambda
string func(int a) => a.ToString();          // local function, expression bodied
(int => string) func = a => a.ToString();    // this proposal

[YaakovDavis]

With #150, the delegate types can be inferred without requiring new syntax.

[TylerBrinkley]

@gulshan local functions do not serve the same purpose as delegates.

[TylerBrinkley]

@YaakovDavis the main purpose of this proposal is to be able to specify named parameters to provide better documentation. The variable declaration syntax is just a natural addition but isn't the primary focus.

[YaakovDavis]

to be able to specify named elements

OK, got it.

[svick]

My thoughts:

1. I don't like the syntax for having no parameters and for having no return value. => just after the opening parenthesis or before the closing parenthesis looks wrong to me. Contrast this with lambdas, where no parameters have a special syntax (()), not just omitting that part of the syntax.
2. This syntax lets you name a return value. That's inconsistent with the rest of C#, where return values don't have names.
3. It should be mentioned that there is already a way to name delegate parameters: by creating a custom delegate type. Though almost nobody uses it.
4. If attributes everywhere (https://github.com/dotnet/roslyn/issues/6671) was implemented, it could allow you to specify parameter names using something like: Func<[[Name("inclusiveMin")]] int, [[Name("exclusiveMax")]] int, [[Name("total")]] int>. It's much more verbose than the syntax proposed here, but maybe that's okay, assuming this wouldn't be used that often.

[TylerBrinkley]

@svick thanks for the great feedback.

1. Would you prefer an empty parenthesis or perhaps the void keyword? I'm open to suggestions.
2. That's true, perhaps only support named output parameters for multiple return values using Tuples.
3. Thanks, I've added that to the original post.
4. Perhaps that's an option but it is very verbose and dependent on that being implemented but would still look terrible in Intellisense for documentation.

[TylerBrinkley]

I'm not sure I mind the empty input parameter or empty return parameter given the required outer parentheses which aren't required for lambdas.

[benaadams]

So for ConcurrentDictionary<TKey, TValue>

Rather than

public TValue AddOrUpdate(
	TKey key,
	Func<TKey, TValue> addValueFactory,
	Func<TKey, TValue, TValue> updateValueFactory
)

It would be something like the following?

public TValue AddOrUpdate(
	TKey key,
	(TKey key => TValue value) addValueFactory,
	(TKey key, TValue oldValue => TValue newValue) updateValueFactory
)

[MgSam]

@svick

This syntax lets you name a return value. That's inconsistent with the rest of C#, where return values don't have names.

The tuple feature was pretty explicitly designed so that you could name the values you were returning from a method. So it's pretty clear naming return values has merit. It's true you can't name non-tuple return values, but that seems more like a consequence of C heritage rather than an intentional design choice around which other design choices should be based.

[TylerBrinkley]

@benaadams yes, that's a great use case for this feature. I'll add a section to the proposal for existing use cases in the BCL.

[CyrusNajmabadi]

If we did this, i'd far prefer us stick with something much more in line with how lambdas are written, and more in line with how TypeScript does this. i.e. (double a, char b) => bool

I also not only don't see the value in naming the return type, but i also think it would be extremely out of place as you can't do this anywhere else in the language. It seems like it would be quite weird to have such a one-off facility just for this construct, when everywhere else in the language this facility would not be available.

The parentheses placement seems decidedly non-csharpish. For example, instead of:

(int count => bool success, int total) i would expect to see:
(int count) => (bool success, int total)

This reuses actual C# syntactic constructs. The grammar production would simply be:

FunctionType:
     FormatParameterList    =>   Type

But i do see a problem you're trying to solve. Namely that now using this type along with a variable name looks quite strange: (int count) => bool predicate. TS benefits from having types on the right, so this reads great: predicate: (count: number) => bool

Maybe a middle ground is:

FunctionType
    (     parameters    =>     Type    )

[CyrusNajmabadi]

The parentheses placement seems decidedly non-csharpish. For example, instead of:

(int count => bool success, int total) i would expect to see:
(int count) => (bool success, int total)

This reuses actual C# syntactic constructs. The grammar production would simply be:

FunctionType:
     FormatParameterList    =>   Type

But i do see a problem you're trying to solve. Namely that now using this type along with a variable name looks quite strange: (int count) => bool predicate. TS benefits from having types on the right, so this reads great: predicate: (count: number) => bool

[MgSam]

@CyrusNajmabadi Maybe then its worth rethinking whether naming return values makes sense in general? It was worthwhile naming the members of tuples, specifically so that you could return multiple values from a method and have them make sense, so why would should it not be worthwhile more generally? Autocompletion could be a lot nicer if it when storing the value returned by a method it could suggest the exact name the author intended.

This is a bit of a tangent though. I think the general feature doesn't require this piece to still be useful.

[TylerBrinkley]

Due to the issue @CyrusNajmabadi mentioned I think the outer parentheses should be required.

I've created the below table to help determine the syntax for when there are no input or return parameters.

	Empty return parameter	Void return parameter
Empty for no input parameters	(=>) (DateTime startDate =>) (int index, string value =>)	(=> void) (DateTime startDate => void) (int index, string value => void)
Parentheses only for no input parameters	(() =>) (DateTime startDate =>) (int index, string value =>)	(() => void) (DateTime startDate => void) (int index, string value => void)
Parentheses around all input parameters	(() =>) ((DateTime startDate) =>) ((int index, string value) =>)	(() => void) ((DateTime startDate) => void) ((int index, string value) => void)
Parentheses around all input parameters except when there's just one	(() =>) (DateTime startDate =>) ((int index, string value) =>)	(() => void) (DateTime startDate => void) ((int index, string value) => void)

The parentheses around all input parameters gets confusing as users may confuse them with tuples. After looking at it I think I prefer the "Parentheses only for no input parameters" and "Void return parameter". What do you all think? Also what do you think about implicitly supporting multiple return parameters using tuples or do you think it should be explicit using tuple syntax?

[svick]

@Grauenwolf My issue with using specific delegate types everywhere is that it's hard to say what the delegate signature is from seeing a signature of a method that accepts it.

For example, consider this method signature:

public static RegisteredWaitHandle RegisterWaitForSingleObject(
	WaitHandle waitObject,
	WaitOrTimerCallback callBack,
	object state,
	uint millisecondsTimeOutInterval,
	bool executeOnlyOnce
)

Now, can you tell me what parameters does the WaitOrTimerCallback delegate take and what is its return type? With Func/Action, that's immediately clear.

[Grauenwolf]

Yea, you do have a point there.

…

-----Original Message----- From: "Petr Onderka" <[email protected]> Sent: ‎3/‎20/‎2017 4:59 PM To: "dotnet/csharplang" <[email protected]> Cc: "Jonathan Allen" <[email protected]>; "Mention" <[email protected]> Subject: Re: [dotnet/csharplang] Proposal: Language support for Func & Action(#269) @Grauenwolf My issue with using specific delegate types everywhere is that it's hard to say what the delegate signature is from seeing a signature of a method that accepts it. For example, consider this method signature: public static RegisteredWaitHandle RegisterWaitForSingleObject( WaitHandle waitObject, WaitOrTimerCallback callBack, object state, uint millisecondsTimeOutInterval, bool executeOnlyOnce )Now, can you tell me what parameters does the WaitOrTimerCallback delegate take and what is its return type? With Func/Action, that's immediately clear. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[HaloFour]

@svick

My issue with using specific delegate types everywhere is that it's hard to say what the delegate signature is from seeing a signature of a method that accepts it.

That sounds like a problem that could be resolved through improved tooling.

I have the inverse opinion. I prefer to define my own delegate types for any non-trivial case as I find that the raw signature conveys nothing as to what targets of that delegate are supposed to do. With a custom delegate type I can name my arguments something obvious and provide my own XML documentation.

[svick]

@HaloFour I agree that that is an issue with Func/Action. Though maybe there are ways to improve that, like #269 (which stores the parameter names in an attribute, similar to tuples)?

[HaloFour]

@svick

Feels backwards to me. Like trying to justify the use of tuples everywhere instead of proper structs/classes as data structures. It wouldn't even be beneficial without accompanying tooling work as its not like the IDE automatically pops in the argument names from the delegate definition into your lambda. And even more compiler/tooling changes to consider XML documentation.

I get the desire to be more succinct, but I'd rather approach it from formal delegate definitions and work in the other direction. I'm not sure that I have any idea how to do that, though. But I don't particularly feel that writing delegate types is that cumbersome anyway.

[jmagaram]

I agree that naming parameters in Func and Action is really important. The problem I have with writing delegate types is figuring out good names for them especially if there are many overloads of a similar concept. Also, and this is less of an issue, I don't like having to define the delegate when it is used in only one place.

[taori]

Why

public TValue AddOrUpdate(
    TKey key,
    (TKey key => TValue) addValueFactory,
    (TKey key, TValue existingValue => TValue) updateValueFactory);

instead of

public TValue AddOrUpdate(
    TKey key,
    Action<TKey key, TValue value> addValueFactory,
    Func<TKey key, TValue existingValue, TValue> updateValueFactory);

though? Less tedious as far as adapting the codebase goes because it only barely changes the syntax. Loving the proposal though.

[TylerBrinkley]

Well, the addValueFactory is actually a Func not an Action which just proves the reason why using the the first syntax reduces confusion. Users don't even need to know the difference between Func and Action, they'll just see the return is a value or void. It's also less typing.

[taori]

Hrm i see. The only downside of having this feature implemented this way then would be compatibility to old code then. Let's see how microsoft decides what syntax it will be if it gets implemented. I sure hope it does get implemented in one way or another

[TylerBrinkley]

The existing explicit syntax of declaring Action and Func will still work but if you want named parameter support then switching to use the new syntax shouldn't be too burdensome. It looks much cleaner too.

[HaloFour]

@TylerBrinkley

Other than a vague mention of "providing better documentation" I don't see anything in this proposal that actually describes how it would improve the development experience.

• Unlike tuples, the argument names of a delegate never come into play. You can't reference them from either the caller or the callee. So it's not like these names would make an appearance in the code itself.
• There's no autocomplete beyond what the IDE offers for event handlers.
• Intellisense only shows types, not names, in the tooltip for the arguments of a method that accepts a delegate. The only time the names appear is when invoking the delegate.
• XML documentation comments offers no way to document the arguments of a delegate that a method happens to accept as a parameter.

How specifically would this proposal address "documentation"? Where would those attributes containing this metadata be used?

Also, by binding the syntax to the ubiquitous Action<...> and Func<...> family of delegates not only does this force the language to take a direct dependency on them (which is currently not the case), it also would make it impossible to use this kind of syntax in any of the scenarios where those delegates cannot be used. For example, if any of the parameters are ref or out. Or if the return type is ref.

I honestly just don't see the point.

[TylerBrinkley]

@HaloFour

Thanks for the thoughts. Due to your feedback I have added sections for considering support for named, optional, and params parameters.

Here are the main advantages by adding this feature.

• In Intellisense or when viewing a Type's definition, when currently seeing Func or Action users would now see them in this new syntax which displays the parameter names if applied which will help code consumers.
• New C# developers won't initially need to know about Func and Action and their type argument orderings which should slightly lower the barrier to entry. It just looks like a function signature
  which is basically what it is.
• Ability to specify named, optional, or params parameters.

[TylerBrinkley]

Switched the proposal to require parentheses around all input parameters as it works better with optional / default parameters as well as params parameters and better matches lambda syntax.

Added open question about whether to support an optional simplified syntax for when there is only one input parameter to not require the surrounding parentheses and if so should it only apply when there is no parameter name associated with the parameter such as (int => string) or should it also apply when there is a parameter name such as (int value => string)?

[truegoodwill]

Please consider not just parameter naming but also documenation. It would be great to comment a Func field declaration like this:

/// <summary>My function</summary>
/// <param name="a">Description of parameter</param>
/// <param name="b">Description of parameter</param>
public Func<int a, int b, int> MyFunc { get; set; }

[jez9999]

Another solution for this, which some may consider hacky, would be #6636. Tuple values can be named - sure, so always use tuples in your Func and Action type parameters. You can do it now, with one problem: shorthand syntax isn't supported for single-element tuples:

public void CropCustomerAccounts(Func<(int CustomerId), (bool AccountExpired)> fnProcessCustomer) {}