I like anonymous types in C#. Syntactically, they fit into the language and provide a lightweight means of creating an immutable type. (It is worth pointing out that Visual Basic's anonymous types can be mutable or immutable.) In many other languages, we would call anonymous types a tuple.
The use case for anonymous types is to support the creation of intermediate types when working with statements and expressions inside a method. Where this is primarily useful is with LINQ expressions.
The problem with anonymous types is that they really don't go far enough. It's like being teased.
"We're going to give you a tuple type. Ok, well, not really. It's like a tuple. Unlike a tuple, you can't pass it easily into a method. You can't return it from a method. Oh yea, you can also forget about easily serializing it too. Other than that, sure, we gave you a tuple."
The designers of both the C# and Visual Basic teams went only about a half way to implementing true tuples in their respective languages.
The problem about coming up short with the tuple implementations is that developers want to use them outside of the local method scopes. I recall when the feature was brought out in the open, comments in the blogs from developers asked for taking them the rest of the way.
Where as with nullable types, the language and CLR teams got together to fix the implementation late in the development cycle of .NET 2.0, the same was not done for anonymous types. And that's even with feedback early in the previews of LINQ well ahead of the betas for Orcas. It's worth noting that unlike nullable types, improving the tuple support would not require an adjustment to the CLR.
It's unfortunate because developers, sometimes unwisely, will plod forward trying to make it work with warts and all. We see hacks found in new toolkits like ASP.NET MVC where an anonymous type is expected into a method that specifies System.Object. You lose type information. Unless you read the documentation, you will not know what the format of the anonymous type should be in.
The method that takes the anonymous type then performs reflection pulling out the values for each of the properties. It can store it in dictionary or copy it to yet another anonymous type.
Developers do these tricks because tuples are useful as a means of working with small groups of related data.
The situation is a little reminiscent of anonymous methods in C# 2.0. Where there were lots of examples of good approaches for creating lambdas/closures (LISP, Python, Ruby, ML, F#, Haskell, and others), the team chose to take an approach more akin to the hairball, anonymous inner classes, Sun coughed up in Java. (I used anonymous inner classes a lot in Java. I found them useful. But, I didn't like them.)
Fortunately, the introduction of anonymous methods did not result in "damages" to libraries. It was just an unpleasant syntax that leveraged delegates with additional capabilities. The libraries could go ahead and use delegates as parameters or return values for methods. If a developer chose to use anonymous methods, fine. If not, they could still use the routines in the libraries. (Visual Basic 2005 did not offer support for anonymous methods, but it could use methods that used delegates with their existing language features for delegates.)
With the introduction of lambdas in C# 3.0 and Visual Basic, developers can use a syntax more akin to the languages that long have paved the way. The existing libraries using delegates could be leveraged with the improved syntax without changes in the libraries themselves.
When true tuple support is added to C# 4.0 and the next version of Visual Basic, libraries will more than likely have to be adapted to utilize the improved support. Sure, existing code using reflection may continue to work with the true tuples. But, if developers want to leverage the type safety offered by the ability to declare the tuple types being pass in or returned, adaptations will likely need to be made to the libraries.
You may note I said when and not if true tuple support is added. Although no announcement has been made by either team, I have a hard time seeing the teams not improving the support for tuple-like types in their respective languages. With the push towards immutability and declarative styles of programming in both languages, having a tuple type is extremely useful.
The following recent posts by Jeffrey Palermo and Jon Skeet inspired this post:
Use caution with anonymous types and other new C# language features
C# 4, part 2: Ideas from other community members