Suppose you use an anonymous type in C#:

var x = new { A = "hello", B = 123.456 };

Ever taken a look at what code is generated for that thing? If you crack open the assembly with ILDASM or some other tool, you’ll see this mess in the top-level type definitions

.class '<>f__AnonymousType0`2'<'<A>j__TPar','<B>j__TPar'>

What the heck? Let’s clean that up a bit. We’ve mangled the names so that you are guaranteed that you cannot possibly accidentally use this thing “as is” from C#. Turning the mangled names back into regular names, and giving you the declaration and some of the body of the class in C#, that would look like:

[CompilerGenerated]
internal sealed class Anon0<TA, TB>
{
  private readonly TA a;
  private readonly TB b;
  public TA A { get { return this.a; } }
  public TB B { get { return this.b; } }
  public Anon0(TA a, TB b)
  { this.a = a; this.b = b; }
  // plus implementations of Equals, GetHashCode and ToString
}

And then at the usage site, that is compiled as:

var x = new Anon0<string, double>("hello", 123.456);

Again, what the heck? Why isn’t this generated as something perfectly straightforward, like:

[CompilerGenerated]
internal sealed class Anon0
{
  private readonly string a;
  private readonly double b;
  public string A { get { return this.a; } }
  public double B { get { return this.b; } }
  public Anon0(string a, double b)
  { this.a = a; this.b = b; }
  // plus implementations of Equals, GetHashCode and ToString
}

Good question. Consider the following. Suppose you have a library assembly, not written by you, that contains the following types:

public class B
{
  protected class P {}
}

Now, in your source code you have:

class D1 : B
{
  void M() 
  { 
    var x = new { P = new B.P() }; 
  }
}

class D2 : B
{
  void M() 
  { 
    var x = new { P = new B.P() }; 
  }
}

We need to generate an anonymous type, or types, somewhere. Suppose we decide that we want the two anonymous types – which have the same types and the same property names – to unify into one type. (We desire anonymous types that are structurally identical to unify within an assembly because that enables scenarios where multiple methods use generic type inference to infer the same anonymous type; you want to be able to pass instances of that anonymous type around between such methods. Perhaps I’ll do an example of that in the new year.)

Where do we generate that type? How about inside D1:

class D1 : B
{
  [CompilerGenerated]
  ??? sealed class Anon0 { public P P { get { ... } } ... }
  void M() 
  { 
    var x = new { P = new B.P() }; 
  }
}

What is the desired accessibilty of Anon0 in the location marked with question marks? It cannot be private or protected, because then D2 cannot see it. It cannot be either public or internal, because then you’d have a public/internal type with a public property that exposes a protected type, which is illegal. Nor can it be either “protected and internal” or “protected or internal” by similar logic. It cannot have any accessibility! Therefore the anonymous type cannot go in D1.  Obviously by identical logic it cannot go in D2. It cannot go in B because you don’t have the ability to modify the assembly containing class B. The only remaining place it can go is in the global namespace. But at the top level an internal type cannot refer to P, a protected nested type. P is only accessible inside a derived class of B but we’ve already ruled all those out.

But we can put the anonymous type at the top level if it never actually refers to P. If we make generic class Anon0<TP> and construct it with P for TP, then P only ever appears inside D1 and D2, and yet the types unify as desired.

Rather than coming up with some weird heuristic that determined when anonymous types needed to be generic, and making them normally typed otherwise, we simply decided to embrace the general solution. Anonymous types are always generated as generic types even when doing so is not strictly necessary. We did extensive performance testing to ensure that this choice did not adversely impact realistic scenarios, and as it turned out, the CLR is really quite buff when it comes to construction of generic types with lots of type parameters.

And with that, I’m off for the rest of the year. Air travel is too expensive this year, so I’m going to miss my traditional family Boxing Day celebration, but I’m sure it’ll be delightful to spend some time in Seattle for the holidays. I hope you all have a safe and festive holiday season, and we’ll see you for more fabulous adventures in 2011.

When you have a nested loop, sometimes you want to “continue” the outer loop, not the inner loop. For example, here we have a sequence of criteria and a sequence of items, and we wish to determine if there is any item which matches every criterion:

match = null;
foreach(var item in items)
{
  foreach(var criterion in criteria)
  {
    if (!criterion.IsMetBy(item))
    {
      // No point in checking anything further; this is not
      // a match. We want to “continue” the outer loop. How?
    }
  }
  match = item;
  break;
}

There are many ways to achieve this. Here are a few, in order of increasing awesomeness:

Technique #1 (ugly): When you have a loop, the continue statement is essentially a goto which branches to the bottom of the loop, just before it does the loop condition test and pops back up to the top of the loop. (Apparently when you spell goto as continue, the “all gotos are all evil all the time” crowd doesn’t bother you as much.) You can of course simply make this explicit:

match = null;
foreach(var item in items)
  {
  foreach(var criterion in criteria)
  {
    if (!criterion.IsMetBy(item))
    {
      goto OUTERCONTINUE;
    }
  }
  match = item;
  break;
  OUTERCONTINUE:
  ;
}

Technique #2 (better): When I see a nested loop, I almost always consider refactoring the interior loop into a method of its own.

match = null;
foreach(var item in items)
{
  if (MeetsAllCriteria(item, critiera))
  {
    match = item;
    break;
  }
}

where the body of MeetsAllCriteria is obviously

foreach(var criterion in criteria)
{
  if (!criterion.IsMetBy(item))
  {
    return false;
  }
}
return true;

Technique #3 (awesome): The “mechanism” code here is emphasizing how the code works and hiding the meaning of the code. The purpose of the code is to answer the question “what is the first item, if any, that meets all the criteria?” If that’s the meaning of the code, then write code that reads more like that meaning:

var matches = from item in items
              where criteria.All(criterion=>criterion.IsMetBy(item))
              select item;
match = matches.FirstOrDefault();

That is, search the items for items that meet every criterion, and take the first of them, if there is one. The code now reads like what it is supposed to be implementing, and of course, if there are no loops in the first place then there’s no need to “continue” at all!

The thing I love most about LINQ is that it enables a whole new way to think about problem solving in C#. It’s gotten to the point now that whenever I write a loop, I stop and think about two things before I actually type “for”:

• Have I described anywhere what this code is doing semantically, or does the code emphasize more what mechanisms I am using at the expense of obscuring the semantics?
• Is there any way to characterize the solution to my problem as the result of a query against a data source, rather than as the result of a set of steps to be followed procedurally?