Creating delegates manually vs using Action/Func delegates

The advent of Action and Func family of delegates has rendered custom delegates less used, but the latter still finds uses. Advantages of custom delegates include:

1. As others have pointed, conveys intent clearly unlike generic Action and Func (Patrik has a very good point about meaningful parameter names).

2. You can specify ref/out parameters unlike the other two generic delegates. For eg, you can have

   public delegate double ChangeListAction(out string p1, ref int p2);
   

   but not

   Func<out string, ref int, double> ChangeListAction;
   

3. Also, with custom delegates you need to write ChangeListAction (I mean the definition) only once somewhere in your code base, whereas if you don't define one you will have to litter everywhere Func<string, int, double> all over. Changing the signature will be a hassle in the latter case - a bad case of not being dry.

4. Can have optional parameters.

   public delegate double ChangeListAction(string p1 = "haha", int p2);
   

   but not

   Func<string, int, double> ChangeListAction = (p1 = "haha", p2) => (double)p2; 
   

5. You can have params keyword for parameters of a method, not so with Action/Func.

   public delegate double ChangeListAction(int p1, params string[] p2);
   

   but not

   Func<int, params string[], double> ChangeListAction;
   

6. Well, if you're truly out of luck and need parameters more than 16 (for the moment) :)

As to merits of Action and Func:

1. It's quick and dirty, and I use it all over. It makes code short if the use-case is trivial (custom delegates have gone out of fashion with me).

2. More importantly, its type compatible across domains. Action and Func are framework defined, and they operates seamlessly as long as the parameter types match. You can't have ChangeSomeAction for ChangeListAction. Linq finds great use of this aspect.

The advantage is clarity. By giving the type an explicit name it is more clear to the reader what it does.

It will also help you when you are writing the code. An error like this:

cannot convert from Func<string, int, double> to Func<string, int, int, double>

is less helpful than one which says:

cannot convert from CreateListAction to UpdateListAction

It also means that if you have two different delegates, both of which take the same types of parameters but conceptually do two entirely different things, the compiler can ensure that you can't accidentally use one where you meant the other.

Declaring a delegate explicitly can help with some type checks. The compiler can make sure that the delegate assigned to the variable is intended to be used as ChangeListAction and not some random action that happens to be compatible with the signature.

However the real value of declaring your own delegate is that it gives it semantic meaning. A person reading the code will know what the delegate is doing by its name. Imagine if you had a class with three int fields but instead you declared an array of three int elements. The array can do the same thing but the names of the fields bring semantic information that is useful to the developers.

You should use Func, Predicate and Action delegates when you are designing a general purpose library like LINQ. In this case the delegates do not have a predefined semantics other than the fact that they will execute and action or be used as a predicate.

On a side note there is a similar tradeoff issue with Tuple vs anonymous type vs declaring your own class. You could just stick everything in a Tuple but then the properties are just Item1, Item2 which tells nothing about the use of the type.