The major problem with this idea is in my favourite feature of C#. In an iterator (a function containing the yield keyword), the code is transformed into a state machine represented by a class. It has to be chopped up into sections, so the function can be “paused” after each yield return. Those pieces must all be in the same function, so sadly lambdas don’t play well with iterators.
There are a couple of possible future language features which would completely solve this, however.
Updated 2010-06-22: I’ve modified the conclusion of this post slightly – all the same information is there but I’m less forthright in my demand that C# be extended to match the capabilities of VB.NET. The reasons why I’ve changed my mind on this are long and complex so I’ll address them in a series of articles about exceptions in the near future.
Updated 2014-12-15: Exception filters are being added to C# 6, which should be out next year. Amazing what can happen in just 6 years! 😛
There’s a feature in the CLR that is exposed in VB.NET and not in C#. Apparently this is a deliberate decision made by the C# team, which so far they’ve stuck to. Unfortunately, it’s a pretty important feature.
Update: Exactly what I want, already implemented, complete with caching of the call site. Also, Microsoft’s Mads Torgersen responds to this suggestion here.
C# 4.0 proposes to add the dynamic keyword to the language. There are a few problems with it:
Having blogged the other day about a different way of doing automatic cleanup, I’ve been mulling it over and also answering a question on StackOverflow, and decided that I need to assemble a taxonomy of resources; what kinds there are, how to recognise them by their distinctive markings, guidelines for upkeep, training, feeding, breeding, etc. And because I’m obsessive-compulsive, I also wanted to develop a complete and rigorous theory of resources from the ground up.
Updated: The downloadable source (see link below) is now tidied up a bit, and also displays any embedded string comparisons in a similar way to NUnit.
This might be useful as a way to write Assert statements in tests. Instead of requiring many different forms of Assert to capture values and intents, we could just have one Assert that accepts a lambda:
The using-statement is just that: a statement. Why does this bug me?
The FileStream object has a Length property. Assuming I have a function Open that returns a FileStream ready for us, it is awfully tempting to do this:
ForEach is regularly proposed as a missing feature in the BCL but has been rejected in the past apparently because it wouldn’t be "functional" enough, doesn’t return anything so calls cannot be chained together in a LINQ-like pipeline, and so on. So here’s a different approach that is undeniably functional, and does support chaining together.