I find the => syntax a little clumsy and it doesn't feel like a C# way of doing things.

For those that haven't looked at LINQ or C# 3.0, the syntax looks like this:

c => c.Name == "London"

The c name defines a reference to a name provided earlier in the composite expression.

Consider now the foreach keyword. When implementing a loop over an object Microsoft could have just overload the for keyword, say like this:

for( string s / myStrings ) { ...

(the "/" hear read as "over", as the variable s is enumerated over the collection)

Instead MS chose to use a separate foreach keyword in the form: foreach( string s in myStrings ). It just feels to me like => should be a keyword instead.

I raised this with Anders. His comment was "yes, we considered that, but what is that keyword?". I thought it should be "in". Anders response was that it is sometimes "in", but sometimes "over" and sometimes something else. This is because lambda expressions might be used in LINQ in a Select() or a Where() or a GroupBy() or an OrderBy() but the way you would describe => would vary in each, because sometimes you are describing the collection, sometimes picking fields, sometimes defining a filter and so on.

I admitted defeat on this one.

Another feature of C# 3.0 is extension methods, which allow you to define an instance method on a type outside of that type. Think about extending System.String to add a MixedCase() method, or extending System.Int32 to add a Factorial() method.

The current syntax looks like this:

public static class MyExtensions
{
    public static string MixedCase( this string source )
    {
        return ...
    }
}

Notice the this keyword on the method argument. This tells the compiler to treat this method like it extends the string type, and to pass in the string's instance variable as a parameter here called source.

In code I might call this method like this:

string foo = "Hello World";
Console.WriteLine( foo.MixedCase() );

My objections to this are twofold:

• The number of parameters on the method is different between the method declaration and the method call, because the compiler implicitly passes the object's instance pointer before the first true parameter. This just doesn't feel right to me.
• Because it extends method syntax (being inside the method's parentheses) this mechanism will not work for properties.

My preferred syntax would be:

public static class MyExtensions
{
    public static string MixedCase() on string source
    {
        return ...
    }
}

Now we've more clearly called that this the method is implemented "on" another type ("on string" in this case). We might also put an "as" keyword to make it read better "on string as source".

Better yet, you can imagine now turning this method into a property:

public static class MyExtensions
{
    public static string MixedCase on string source
    {
    get { return ... }
    }
}

Anders saw where I was coming from but said there are still quite a few other constraints they have to work through and my solution still has the same constraints as their current implementation (which is obviously true).

C# 3.0's LINQ system and lambda expressions originated in a number of different initiatives. The two main parents are ObjectSpaces (which moved into WinFS then got superceced by LINQ) and the second is Cw (pronounced like "See Omega"). Cw was an interesting language because it introduced a lot of XSD schema functionality into the C# language, in particular the idea of facets (constraints) and support of "choice".

Facets provide a way to declarative implement business rules such as "There must be exactly two addresses" or "Age must be between 16 and 70". I don't really lament the loss of facet support in C# 3.0 because that code is fairly easy to write, and more importantly is easy to read.

Choice is a different matter. Using "choice" in XSD allows you to constrain a type, e.g. to say that an object called Lunch must refer to either Pasta or Burrito or Lasagna but nothing else. In generics today you could say that all the types you want to chose between share some base class (say, "Food"). Consider though an Italian restaurant that wants its options to just be "Pasta" or "Lasagna" and not accept "Burrito". To write code to ensure this is quite annoying, as XSD doesn't require the types to even share a common base. In C# that means you're back to using ArrayList and doing type checks and casting, and generics doesn't buy you anything.

The proposal I made to Anders was to allow for something like this:

List<Pasta or Lasagna>

That is to say that the generic T in the definition of List could reference on of several types. The expanded code could then provide explicit case operators that allowed you to get at a particular type, or else you write code like this:

var myList = new List<Pasta or Lasagna>();
myList.Add( new Pasta() );
Pasta p = myList[0] as Pasta; // p gets the value
Lasagna l = myList[0] as Lasagna; // l will be null

Anders thought this was a nice idea, but I don't see it happening in C# 3.0.