While I'm not fully understanding your insights about "true anonymous functions", "not prefixed by a data type" etc, I can explain you how applications written in C# call methods.

First of all, there is no such a thing "function" in C#. Each and every executable entity in C# is in fact a method, that means, it belongs to a class. Even if you define lambdas or anonymous functions like this:

collection.Where(item => item > 0);

the C# compiler creates a compiler-generated class behind the scenes and puts the lambda body return item > 0 into a compiler-generated method.

So assuming you have this code:

class Example
{
    public static void StaticMethod() { }
    public void InstanceMethod() { }
    public Action Property { get; } = () => { };
}

static class Program
{
    static void Main()
    {
        Example.StaticMethod();
        var ex = new Example();
        ex.InstanceMethod();
        ex.Property();
    }
}

The C# compiler will create an IL code out of that. The IL code is not executable right away, it needs to be run in a virtual machine.

The IL code will contain a class Example with two methods (actually, four - a default constructor and the property getter method will be automatically generated) and a compiler-generated class containing a method whose body is the body of the lambda expression.

The IL code of Main will look like this (simplified):

call void Example::StaticMethod()
newobj instance void Example::.ctor()
callvirt instance void Example::InstanceMethod()
callvirt instance class [mscorlib]System.Action Example::get_Prop()
callvirt instance void [mscorlib]System.Action::Invoke()

Notice those call and callvirt instructions: these are method calls.

To actually execute the called methods, their IL code needs to be compiled into machine code (CPU instructions). This occurs in the virtual machine called .NET Runtime. There are several of them like .NET Framework, .NET Core, Mono etc.

A .NET Runtime contains a JIT (just-in-time) compiler. It converts the IL code to the actually executable code during the execution of your program.

When the .NET Runtime first encounters the IL code "call method StaticMethod from class Example", it first looks in the internal cache of already compiled methods. When there are no matches (which means this is the first call of that method), the Runtime asks the JIT compiler to create such a compiled-and-ready-to-run method using the IL code. The IL code is converted into a sequence of CPU operations and stored in the process' memory. A pointer to that compiled code is stored in the cache for future reuse.

This all will happen behind the call or callvirt IL instructions (again, simplified).

Once this happened, the Runtime is ready to execute the method. The CPU gets the compiled code's first operation address as the next operation to execute and goes on until the code returns. Then, the Runtime takes over again and proceeds with next IL instructions.

The DynamicInvoke method of the delegates does the same thing: it instructs the Runtime to call a method (after some additional arguments checks etc). The "dead end" you mention RuntimeMethodHandle.InvokeMethod is an intrinsic call to the Runtime directly. The parameters of this method are:

• object target - the object on which the delegate invokes the instance method (this parameter).
• object[] arguments - the arguments to pass to the method.
• Signature sig - the actual method to call, Signature is an internal class that provides the connection between the managed IL code and native executable code.
• bool constructor - true if this is a constructor call.

So in summary, methods are not represented as objects in C# (while you of course can have a delegate instance that is an object, but it doesn't represent the executable method, it rather provides an invokable reference to it).

Methods are called by the Runtime, the JIT compiler makes the methods executable.

You cannot define a global "function" outside of classes in C#. You could get a direct native pointer to the compiled (jitted) method code and probably even call it manually by directly manipulating own process' memory. But why?

You clearly misunderstand main differences between script languages, C/C++ and C#.

I guess the main difficulty is that there is no such thing as a function in C#. At all. C#7 introduced the new feature "a local function", but that is not what a function in JS is. All pieces of code are methods. That name is intentionally different from function or a procedure to emphasize the fact that all executable code in C# belongs to a class.

Anonymous methods and lambdas are just a syntax sugar. A compiler will generate a real method in the same (or a nested) class, where the method with anonymous method declaration belongs to.

This simple article explains it. You can take the examples, compile them and check the generated IL code yourself.

So all the methods (anonymous or not) do belong to a class. It's impossible to answer your updated question, besides saying It does not store a reference to a function, as there is no such thing in C#.

How does one store a reference to a method?

Depending on what you mean by reference, it can be either

1. An instance of MethodInfo class, used to reference reflection information for a method,
2. RuntimeMethodHandle (obtainable via RuntimeMethodInfo.MethodHandle) stores a real memory pointer to a JITed method code
3. A delegate, that is very different from just a memory pointer, but logically could be used to "pass a method reference to another method" .

I believe you are looking for the MethodInfo option, it has a MethodInfo.Invoke method which is very much alike Function..apply function in JS. You have already seen in the Delegate source code how that class is used.

If by "reference" you mean the C-style function pointer, it is in RuntimeMethodHandle struct. You should never use it without solid understanding how a particular .Net platform implementation and a C# compiler work.

Hopefully it clarifies things a bit.

A delegate is simply a pointer(memory location to jump to) to a method with the specified parameters and return type. Any Method that matches the signature(Parameters and return type) is eligible to fulfill the role, irrespective of the defined object. Anonymous simply means the delegate is not named.

Most times the type is implied(if it is not you will get a compiler error): C# is a strongly typed language. That means every expression (including delegates) MUST have a return type(including void) as well as strongly typed parameters(if any). Generics were created to permit explicit types to be used within general contexts, such as Lists.

To put it another way, delegates are the type-safe managed version of C++ callbacks.

Delegates are helpful in eliminating switch statements by allowing the code to jump to the proper handler without testing any conditions.

A delegate is similar to a Closure in Javascript terminology.

In your response to Amy, you are attempting to equate a loosely typed language like JS, and a strongly typed language C#. In C# it is not possible to pass an arbitrary(loosely-typed) function anywhere. Lambdas and delegates are the only way to guarantee type safety.

I would recommend trying F#, if you are looking to pass functions around.

EDIT:

If you are trying to mimic the behavior of Javascipt, I would try looking at using inheritance through Interfaces. I can mimic multiple inheritance, and be type safe at the same time. But, be aware that it cannot fully supplant Javascript's dependency injection model.

As you probably found out C# doesn't have the concept of a function as in your JavaScript example.

C# is a statically typed language and the only way you can use function pointers is by using the built in types (Func,Action) or custom delegates.(I'm talking about safe,strongly typed pointers)
Javascript is a dynamic language that's why you can do what you describe

If you are willing to lose type safety, you can use the "dynamic" features of C# or refection to achieve what you want like in the following examples (Don't do this,use Func/Action)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;

namespace ConsoleApp1
{
    class Program
    {
        private static Dictionary<string, Func<int, int, int>> FuncOps = new Dictionary<string, Func<int, int, int>>
        {
            {"add", (a, b) => a + b},
            {"subtract", (a, b) => a - b}
        };

        //There are no anonymous delegates
        //private static Dictionary<string, delegate> DelecateOps = new Dictionary<string, delegate>
        //{
        //    {"add", delegate {} }
        //};

        private static Dictionary<string, dynamic> DynamicOps = new Dictionary<string, dynamic>
        {
            {"add", new Func<int, int, int>((a, b) => a + b)},
            {"subtract", new Func<int, int, int>((a, b) => a - b)},
            {"inverse", new Func<int,  int>((a) => -a )} //Can't do this with Func
        };

        private static Dictionary<string, MethodInfo> ReflectionOps = new Dictionary<string, MethodInfo>
        {
            {"abs", typeof(Math).GetMethods().Single(m => m.Name == "Abs" && m.ReturnParameter.ParameterType == typeof(int))}
        };

        static void Main(string[] args)
        {

            Console.WriteLine(FuncOps["add"](3, 2));//5
            Console.WriteLine(FuncOps["subtract"](3, 2));//1

            Console.WriteLine(DynamicOps["add"](3, 2));//5
            Console.WriteLine(DynamicOps["subtract"](3, 2));//1
            Console.WriteLine(DynamicOps["inverse"](3));//-3

            Console.WriteLine(ReflectionOps["abs"].Invoke(null, new object[] { -1 }));//1
            Console.ReadLine();
        }
    }
}

one more example that you shouldn't use

delegate object CustomFunc(params object[] paramaters);
private static Dictionary<string, CustomFunc> CustomParamsOps = new Dictionary<string, CustomFunc>
{
    {"add", parameters => (int) parameters[0] + (int) parameters[1]},
    {"subtract", parameters => (int) parameters[0] - (int) parameters[1]},
    {"inverse", parameters => -((int) parameters[0])}
};

Console.WriteLine(CustomParamsOps["add"](3, 2)); //5
Console.WriteLine(CustomParamsOps["subtract"](3, 2)); //1
Console.WriteLine(CustomParamsOps["inverse"](3)); //-3

I will provide a really short and simplified answer compared to the others. Everything in C# (classes, variables, properties, structs, etc) has a backed with tons of things your programs can hook into. This network of backend stuff slightly lowers the speed of C# when compared to "deeper" languages like C++, but also gives programmers a lot more tools to work with and makes the language easier to use. In this backend is included things like "garbage collection," which is a feature that automatically deletes objects from memory when there are no variables left that reference them. Speaking of reference, the whole system of passing objects by reference, which is default in C#, is also managed in the backend. In C#, Delegates are possible because of features in this backend that allow for something called "reflection."

From Wikipedia:

Reflection is the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime.

So when C# compiles and it finds a Delegate, it is just going to make a function, and then store a reflective reference to that function in the variable, allowing you to pass it around and do all sorts of cool stuff with it. You aren't actually storing the function itself in the variable though, you are storing a reference, which is kinda like an address that points you to where the function is stored in RAM.