title: Why does calling an explicit interface implementation on a value type cause it to be boxed?
body: <p>My question is somewhat related to this one: <a href="https://stackoverflow.com/questions/5531948/how-does-a-generic-constraint-prevent-boxing-of-a-value-type-with-an-implicitly-i">How does a generic constraint prevent boxing of a value type with an implicitly implemented interface?</a>, but different because it shouldn't need a constraint to do this because it's not generic at all.</p>
  
  <p>I have the code</p>
  
  <pre><code>interface I { void F(); }
  struct C : I { void I.F() {} }
  static class P {
      static void Main()
      {    
          C x;
          ((I)x).F();
      }
  }
  </code></pre>
  
  <p>The main method compiles to this:</p>
  
  <pre><code>IL_0000:  ldloc.0
  IL_0001:  box        C
  IL_0006:  callvirt   instance void I::F()
  IL_000b:  ret
  </code></pre>
  
  <p>Why doesn't it compile to this?</p>
  
  <pre><code>IL_0000:  ldloca.s   V_0
  IL_0002:  call       instance void C::I.F()
  IL_0007:  ret
  </code></pre>
  
  <p>I see why you need a method table to make a virtual call, but you don't need to make a virtual call in this case. If the interface is implemented normally it doesn't make a virtual call.</p>
  
  <p>Also related: <a href="https://stackoverflow.com/questions/1392252/c-what-is-the-reason-for-explicitly-implemented-interface-members-are-always">Why are explicit interface implementations private?</a> - the existing answers on this question don't adequately explain why the methods are marked as private in the metadata (rather than merely having unusable names). But even this doesn't fully explain why it's boxed, since it still boxes when called from inside C.</p>