Action's counterpart for methods that hand something back — the delegate type behind almost every LINQ method you're about to learn.

Action covers "do something, return nothing." But what about "compute something and give me the answer"? A price calculator, a validator that returns true/false, a transformer that turns a string into an int — all of these need to hand a result back to whoever called them.

That's exactly what Func is for. If Action is "do this," Func is "compute this and give it back to me." Together, they cover almost every delegate shape you'll write in day-to-day C#.

What Is It?

The Simple Explanation

Func is a built-in generic delegate type representing "a method that takes some arguments and returns a value." Like Action, it comes in multiple generic flavors — but every Func variant's last type parameter is always the return type.

The Technical Definition

public delegate TResult Func<TResult>();
public delegate TResult Func<T, TResult>(T arg);
public delegate TResult Func<T1, T2, TResult>(T1 arg1, T2 arg2);
// ...continues up to Func<T1, ..., T16, TResult>

Read Func<T1, T2, TResult> as: "takes a T1 and a T2, returns a TResult." The very last type parameter is always the return type — everything before it is a parameter, in order.

Why Does It Exist?

The Problem — Action Can't Return Anything

Action is always void. There's no way to squeeze a return value out of it — the delegate type itself forbids it at compile time. As soon as you need to pass in "logic that computes something and hands it back" (a comparison, a transformation, a validation check), Action simply doesn't fit.

The Solution — A Parallel Family for Return Values

Func mirrors Action's design (generic, multiple arities, no new type declarations needed) but adds exactly one thing: a mandatory return type as the final type parameter. Between Action and Func, the BCL covers essentially every "pass behavior as data" scenario you'll encounter — which is precisely why LINQ, which you'll study right after this module, is built almost entirely on Func delegates (Where takes a Func<T, bool>, Select takes a Func<T, TResult>, and so on).

Big Picture

How It Works

Func<string, int, bool>

bool SomeMethod(string s, int n)

Simple Example

using System;

class Program
{
    static int Square(int x) => x * x;
    static bool IsPositive(int x) => x > 0;
    static int Add(int a, int b) => a + b;

    static void Main()
    {
        Func square = Square;
        Func isPositive = IsPositive;
        Func add = Add;

        Console.WriteLine(square(5));           // 25
        Console.WriteLine(isPositive(-3));       // False
        Console.WriteLine(add(4, 6));            // 10

        // Passing a Func into another method
        PrintResult(square, 7);   // "Result: 49"
        PrintResult(isPositive, -1); // "Result: False" (bool prints fine as object here via generics)
    }

    static void PrintResult(Func operation, int input)
    {
        T result = operation(input);
        Console.WriteLine($"Result: {result}");
    }
}

Code → Meaning → Result: PrintResult is generic over the return type of the Func it receives — it doesn't care whether the operation returns an int or a bool, only that it's a Func<int, T> for some T. This kind of generic, behavior-accepting method is exactly the shape LINQ methods take.

Real-World Example

A validation pipeline that runs a list of independent business rules against an order, each expressed as a Func<Order, bool>, and reports every rule that failed:

using System;
using System.Collections.Generic;

public record Order(decimal Total, string CustomerEmail, int ItemCount);

public class OrderValidator
{
    private readonly List<(string RuleName, Func IsValid)> _rules = new();

    public void AddRule(string name, Func rule) => _rules.Add((name, rule));

    public List Validate(Order order)
    {
        var failures = new List();
        foreach (var (name, isValid) in _rules)
        {
            if (!isValid(order))
                failures.Add($"Failed rule: {name}");
        }
        return failures;
    }
}

class Program
{
    static void Main()
    {
        var validator = new OrderValidator();
        validator.AddRule("Total must be positive", o => o.Total > 0);
        validator.AddRule("Must have at least one item", o => o.ItemCount > 0);
        validator.AddRule("Email must look valid", o => o.CustomerEmail.Contains('@'));

        var badOrder = new Order(Total: -5m, CustomerEmail: "not-an-email", ItemCount: 0);
        var failures = validator.Validate(badOrder);

        foreach (var failure in failures)
            Console.WriteLine(failure);
        // Failed rule: Total must be positive
        // Failed rule: Must have at least one item
        // Failed rule: Email must look valid
    }
}

OrderValidator never needs to change when a new rule is added — new rules are just new Func<Order, bool> values registered with AddRule. This is a small preview of the "pipeline of predicates" pattern you'll use constantly once you reach Where in LINQ.

Analogy

Under the Hood

Just like Action, Func is an ordinary MulticastDelegate generated once and instantiated per closed generic type at JIT time. One detail worth knowing: Func delegates can be multicast (chained with +=) just like Action, but as covered in lesson 097, invoking a multicast non-void delegate only surfaces the last subscriber's return value — every earlier subscriber still runs, but its result is silently discarded. In practice, most Func usage is single-subscriber precisely to avoid this trap.

Common Confusion

1. Which type parameter is the return type?

Always the last one — no exceptions. Func<int> (one type parameter) takes no parameters and returns int. Func<int, int> (two type parameters) takes one int parameter and returns an int. This trips up beginners because both look similar at a glance.

2. Func vs a method that just... returns something

A regular method that returns a value is not itself a Func — it only becomes a Func value when you assign or pass it as a method group (Func<int,int> f = Square;) or write it as a lambda. Declaring a method with a return type doesn't automatically make it usable as a delegate — you still need to reference it that way explicitly.

Common Mistakes

Mistake 1 — Miscounting parameters vs the return type

Writing Func<int, string, bool> when you meant "takes a string, returns a bool" — that signature actually means "takes an int and a string, returns a bool."

Count backward from the end: the last type parameter is the return type; everything before it, left to right, is the parameter list in order.

Mistake 2 — Multicasting a Func and expecting every result

Chaining several handlers onto one Func<T, TResult> with += and assuming the invocation somehow aggregates all their results.

Keep Func single-subscriber for value-returning scenarios; use a plain List<Func<...>> (as in the validator example above) when you genuinely need to run several and inspect every result.

When Should I Use It?

• Whenever the passed-in behavior needs to compute and return something — filtering rules, transformations, comparisons, factories.
• Any time you're about to write your own predicate/transform delegate — check the parameter count first; Func almost certainly already fits.
• As the return type of a method that produces a "recipe" instead of a final value — e.g., a factory method returning Func<int, Order> to build orders lazily.

Mental Model

Key Takeaway

Check Your Understanding

You've learned how to read and use Func. Let's confirm it clicked.

You can now read and write Func signatures confidently. Next: Predicate<T>, a specialized shape you'll recognize instantly now that you understand Func<T, bool>.

dotnetmadeeasy.com — Learn C# and .NET, the right way.