C# language doesn't need the concept of delegates?

C++ allows passing of (generic) function pointers simply, as follows: How to pass a generic function pointer as parameter
Java uses interfaces for this - also elegant from an OO perspective, we use nothing more than what the basic language already supplies.

However, I have never seen any real advantage to making delegate an explicit concept / keyword, as opposed to just managing the concept of callbacks the way that for example C++ or Java do -- by treating function pointers as just another circumstance under existing type system. (P.S. yes, C# generics are not the same as C++ generics, while Java has runtime rather than compile-time generics, but you get my drift).

(All hubris and dogma aside) Why did the designers of C# see fit to give a new name to a common, existing programming concept that could have been called a generic function pointer / callback? Could delegates not have been more simply represented in C#, without such a concept?

DISCLAIMER I've looked at quite a number of answers on stackoverflow and not one of them has satisfactorily answered why the designers saw fit to include another keyword for something so fundamental as callback handling.

Solution

C++ had "official" (non-Boost) "full" delegates from C++11 (std::function)... Before that, getting a pointer to a member function was always a little hackish... So I wouldn't consider C++ to be a good comparison :-) And C++ can overload the round parenthesis, so it is more easy to "hide" the hacks that need to be done and give to the programmer a "simple" way of using the std::function.

Now... Java... To "correct" (but let's say it wasn't an omission, but a calculated decision, so they didn't have anything to correct) the missing delegate concept they first had to introduce anonymous classes in Java 1.1 and then in Java 8 they introduced functional interfaces (as a non-Java programmer, I consider the last thing to be a little hackish... meta-describing that an interface has a single method and then enforcing it at compile time... I don't like it very much...). This because otherwise the boilerplate code that is needed is quite much...

Let's start simple... The IComparer<> interface... It is an interface with a single method, so it is very similar to a delegate...

a simple implementation:

public class MyComparer : IComparer<int>
{
    public int Compare(int x, int y)
    {
        return x.CompareTo(y);
    }
}

There is a boilerplate row here, the first one (public class MyComparer : IComparer<int>). By introducing the C# delegate you already gained one row for each use of a delegate... But wait! Let's say that your "delegate" needs a reference to the class that "contains" it...

public class MyComparer : IComparer<int>
{
    public MyClass Target;

    public int Compare(int x, int y)
    {
        return Target.Ascending ? x.CompareTo(y) : y.CompareTo(x);
    }
}

And now this class needs to be a nested class of MyClass. Note that I don't have anything against nested classes...

We have added a new line (public MyClass Target)... But this code is normally wrong to write... You shouldn't have public non-readonly fields. You could use an auto-property public MyClass Target { get; set; } but that too is synctactic sugar introduced in C# 3.0... without them the boilerplate code would grow... And I would prefer to have a private readonly MyClass Target.. But then I would have to add four lines for the constructor... How many lines do you want me to write for a delegate? :-)

And still C#/.NET delegates give more flexibility: the function you use can have any name, so you can have multiple of them in the same class... The MyComparer could have been implemented as two methods:

public int CompareAscending(int x, int y) {}

and

public int CompareDescending(int x, int y) {}

without adding too much code, or splitting everything in multiple (nested) classes.