Introduction

In C#, Func always represents a delegate that returns a value. If you need a delegate with no return value, the correct type is Action. This sounds simple, but confusion appears often when moving between lambda expressions, async callbacks, events, and reusable API signatures.

Func Always Has a Return Type

The generic signature of Func ends with the return type parameter. All earlier type parameters are input arguments.

Examples:

• Func<int> means no inputs, returns int.
• Func<int, string> means one int input, returns string.
• Func<int, int, bool> means two int inputs, returns bool.

Func<int, int, int> add = (a, b) => a + b;
int result = add(2, 5);
Console.WriteLine(result);

If a lambda does not return a value, it cannot be assigned to Func.

Use Action for No Return Delegates

Action is the delegate family for methods that return void.

Action<string> log = message => Console.WriteLine($"LOG: {message}");
log("started");

Common Action forms:

• Action for zero inputs.
• Action<T> for one input.
• Action<T1, T2, ...> for multiple inputs.

In practical code, this maps naturally to side effect callbacks like logging, publishing notifications, and updating UI state.

That difference is useful for code review too. When a parameter is typed as Action, readers immediately know the callback is being invoked for its effect rather than for a computed result that must be captured.

How to Choose Between Func and Action

Use this rule:

• If callback computes and returns something, use Func.
• If callback only performs work, use Action.

Example API design:

1public static int ExecuteAndReturn(int x, Func<int, int> operation)
2{
3    return operation(x);
4}
5
6public static void ExecuteSideEffect(int x, Action<int> operation)
7{
8    operation(x);
9}

Clear delegate intent improves readability and reduces misuse by API consumers.

Lambdas and Method Groups

Delegates can be created from lambda expressions or method groups.

1static int Square(int x) => x * x;
2static void PrintSquare(int x) => Console.WriteLine(x * x);
3
4Func<int, int> f = Square;
5Action<int> a = PrintSquare;
6
7Console.WriteLine(f(4));
8a(4);

Method groups are useful when named methods are easier to test or reuse than inline lambdas.

Delegates in LINQ and Async Code

LINQ commonly uses Func delegates for projections and filters.

var nums = new[] { 1, 2, 3, 4 };
var evens = nums.Where(n => n % 2 == 0);

Async flows may mix both styles:

1Func<Task<int>> fetchCount = async () =>
2{
3    await Task.Delay(50);
4    return 42;
5};
6
7Action<int> show = count => Console.WriteLine($"count: {count}");
8show(await fetchCount());

Here, the asynchronous producer returns data through Func, while the consumer side effect uses Action.

Custom Delegates Still Have a Place

Func and Action cover many use cases, but custom delegates can improve intent when parameter meaning is domain specific.

delegate bool RetryPolicy(int attempt, Exception error);

Named delegates can make complex callback signatures clearer than generic tuples of type parameters.

Another example is when a callback has semantic meaning in a public API, such as MessageHandler or ConnectionLostHandler. A named delegate communicates intent better than a generic Action<string>, especially in shared libraries.

Async Variants and Return Semantics

When callbacks are asynchronous, the same principle applies. A callback that returns Task or Task[T] should use Func because there is still a return value, even if it is asynchronous.

1Func<int, Task> saveAsync = async id =>
2{
3    await Task.Delay(10);
4    Console.WriteLine($\"saved {id}\");
5};
6
7Func<int, Task<bool>> validateAsync = async id =>
8{
9    await Task.Delay(10);
10    return id > 0;
11};

Using Action for asynchronous lambdas can hide returned tasks and make error handling harder. Prefer explicit Func signatures so callers can await completion and handle failures correctly.

Common Pitfalls

• Trying to represent a void callback with Func.
• Using Action where a result should be returned and tested.
• Creating complex delegate signatures without documenting callback contract.
• Hiding important return semantics inside side effect delegates.
• Overusing custom delegates when Func or Action is already clear.

Summary

• Func always includes a return type and is for value producing callbacks.
• Action is the correct delegate family for no return callbacks.
• Choose delegate type based on callback intent, not style preference.
• Use method groups or lambdas depending on readability and reuse needs.
• Keep callback contracts explicit so delegate based APIs remain maintainable.