After reading the stack overflow discussion, it's clear there are some reasonable arguments, particularly that it is not good for interoperating with other languages on the CLR.
However, it also appears that most people on that discussion would disagree with my point #2 (code using this becomes more readable). That's probably where the interesting things come in to play.
For me, I don't care about abuse of syntax, etc. as long as code does what a casual observer would guess it does. Perhaps I'm spoiled by working somewhere where people actually write readable code, and if I worked somewhere else, I would want to forbid any syntax magic whatsoever, but more likely I would just be updating my resume :)
Python's optional arguments feature is useful for these kinds of polymorphic usages - and I miss them every time I program in other languages (especially Java). In JavaScript I miss named arguments (e.g. def fun(name, age, gender=1, height=None)), which is very useful especially if one calls stuff like Person("Bob", 13, height=150).
Generally, I don't think these kind of improvements are appreciated in C# as they are polymorphic and make it much harder for the compiler.
The optional arguments feature is to define a function like def fun(..., **kw)
"=>" is the C# lambda operator, which makes an anonymous function. Args go on the left of it, the return value on the right. In most cases, the names given to args don't matter.
C# programmers everywhere are heartened by your condescension. Not. Thinking of it as a pair is not going to help you understand it.
from TFA:
The syntactic trick is how the API uses the name of the lambda’s parameter as the name of the HTML attribute
If your function is passed a function of one parameter, then it is a bit of a hack to vary behaviour based on the name of that parameter. But I'm OK with it, since it works quite well.
I don't get what the problem is. This seems equivalent to Hibernate using reflection on fields in Java classes. Distilling your own syntactic sugar can be a great thing.
As a rubyist who also programs in c#, i'd say that this is pretty gross. Internal DSLs are part of the ruby culture. In c#, the ability to look at code and understand its execution and its intent is the objective. With syntax manipulation like this, the underpinnings of the language that are normally hidden now must be considered... it is out of character.
LINQ is an internal DSL, and it's a big selling point of the C# 3.5 release. I don't think I'd go as far as to call it " one of C#'s main selling points".
The thing is, c# coders cannot build their own LINQ-style DSLs in c#. Rubyists do build thier own DSLs in Ruby.
I personally do not like it. My problem with it is not readability (because it looks very clean) but consistency. When developing an API I always strive to make it as intuitive to use. My #1 goal is always, could you use this without documentation? This hack would make me answer no, its too inconsistent from the norm. I can only hope he mentions how to use it in the ///<summary> comment
My argument for why this is good seems pretty simple:
1) The code that does this isn't that hard to understand
2) All code that uses it becomes much more readable
3) The total of all code in #2 is going to be modified more often by several orders of magnitude than the code in #1