title: Delegates in .NET: how are they constructed?
body: <p>While inspecting delegates in C# and .NET in general, I noticed some interesting facts:</p>
  
  <p>Creating a delegate in C# creates a class derived from <code>MulticastDelegate</code> with a constructor:</p>
  
  <blockquote>
  <pre><code>.method public hidebysig specialname rtspecialname instance 
     void .ctor(object 'object', native int 'method') runtime managed { }
  </code></pre>
  </blockquote>
  
  <p>Meaning that it expects the instance and a pointer to the method. Yet the syntax of constructing a delegate in C# suggests that it has a constructor</p>
  
  <blockquote>
  <pre><code>new MyDelegate(int () target)
  </code></pre>
  </blockquote>
  
  <p>where I can recognise <code>int ()</code> as a function instance (<code>int *target()</code>  would be a function pointer in C++). So obviously the C# compiler picks out the correct method from the method group defined by the function name and constructs the delegate. So the first question would be, where does the C# compiler (or Visual Studio, to be precise) pick this constructor signature from ? I did not notice any special attributes or something that would make a distinction. Is this some sort of compiler/visualstudio magic ? If not, is the <code>T (args) target</code> construction valid in C# ? I did not manage to get anything with it to compile, e.g.:</p>
  
  <blockquote>
    <p>int () target = MyMethod;</p>
  </blockquote>
  
  <p>is invalid, so is doing anything with <code>MyMetod</code>, e.g. calling <code>.ToString()</code> on it (well this does make some sense, since that is technically a method <em>group</em>, but I imagine it should be possible to explicitly pick out a method by casting, e.g. <code>(int())MyFunction</code>. So is all of this purely compiler magic ? Looking at the construction through reflector reveals yet another syntax:</p>
  
  <blockquote>
    <p>Func CS$1$0000 = new Func(null, (IntPtr) Foo);</p>
  </blockquote>
  
  <p>This is consistent with the disassembled constructor signature, yet this does not compile!</p>
  
  <p>One final interesting note is that the classes <code>Delegate</code> and <code>MulticastDelegate</code> have yet another sets of constructors:</p>
  
  <blockquote>
    <p>.method family hidebysig specialname rtspecialname instance 
         void .ctor(class System.Type target, string 'method') cil managed</p>
  </blockquote>
  
  <p>Where does the transition from an instance and method pointer to a type and a string method name occur ? Can this be explained by the <code>runtime managed</code> keywords in the custom delegate constructor signature, i.e. does the runtime do it's job here ?</p>
  
  <p><strong>EDIT</strong>: ok, so I guess I should reformulate what I wanted to say by this question. Basically I'm suggesting that there's not only C# compiler / CLR magic involved in delegate construction, but also some <em>Visual Studio</em> magic, since Intellisense flips out some new syntax when suggesting the constructor arguments and even hides one of them (e.g. Reflector does not use this syntax and construtor, for that matter). </p>
  
  <p>I was wondering whether this assertion is true, and whether the function instance syntax has some deeper meaning in C# or is it just some constant format implemented by the Visual Studio magic part for clarity (which makes sense, since it looks like invalid C#) ? In short, if I was implementing Intellisense, should I do some magic for delegates or could I construct the suggestion by some clever mechanism ?</p>
  
  <p><strong>FINAL EDIT</strong>: so, the popular consensus is that that's indeed VS magic. Seeing other examples (see Marc Gravell's comment) of such VS behavior convinces me that that is the case.</p>