As an aside, Dynamic LINQ (a third-party library) does work that way: OrderByDescending("DatePosted").
–
mellamokbMar 7 '13 at 3:23

3

And what does this have to with Jeopardy or obfuscation?
–
mellamokbMar 7 '13 at 3:24

2

In keeping with the Jeopardy theme, and to answer your question about DatePosted, "What is not a method with the signature Func<TSource, TKey>"?
–
Simon MᶜKenzieMar 7 '13 at 3:53

@mellamokb: Jeopardy forces you to word things according to their expected way "just because" (it's a power trip or something); obfuscation? Yes, to me it is, when simply leaving out all that "c equals arrow c dot" would be clearer.
–
B. Clay ShannonMar 7 '13 at 5:36

I'm just lambda-happy. It reduces a lot of one shot method.
–
Ken KinMar 8 '13 at 13:23

I prefer that syntax for the reasons you state: it's easier to read and it emphasizes the semantics of the query in the business domain rather than the fact that the ordering mechanism requires a key selection function.

The compiler will deduce that DatePosted is the function to call to obtain the sort key and construct a delegate appropriately. (Note that it will also deduce the types correctly and work out that you meant OrderByDescending<Record, DateTime>.)

More generally though: a basic design principle of C# is that the language does not guess what you meant except in certain very well-defined situations(*). A query can be ordered by literally anything, and it is therefore beholden upon the author of the code to clearly state what the sort key is. In the query syntax, the range variables that represent elements of the collection are available so that you can easily expression "order by the date associated with each record". To just say "order by the date" would then involve making a guess.

For the lambda syntax, the method requires a function that selects the order key. You can supply the required a function by supplying a value of delegate type, a lambda convertible to a value of delegate type, or a method group convertible to a value of delegate type, as you see fit. A "naked" property is not a function.

So, could the C# language have been designed so that when you provide the name of a property without any context explaining what its a property of, that the compiler makes a guess? That it says "oh, I see there's a method called OrderBy here that takes a function and a sequence, let me make a guess that the name supplied for the function is intended to be the function "fetch this property off of a given element of the sequence"? Sure, I could have done that. The code is not that much harder to write. But that would not be in keeping with the design principles of the C# language. The benefit of saving a couple keystrokes is not worth the pain of violating the design principle that the intent is unambiguously stated in the code.

(*) Like implicitly typed locals, method type inference, implicitly typed arrays, and overload resolution, all of which involve the compiler making a best guess as to what the developer intended. The rules for making those guesses are carefully documented and have been designed so that most will bail out early if any ambiguity is detected.

@OP: And of course, the reason the c=>c. is necessary if you do not provide a method is because allowing both features would make the code ambiguous in the case that both a method and an instance field or property exists. I prefer method group sugar over field/property sugar, since adding new fields requires modifying the underlying class (which you may not have access to).
–
BrianMar 7 '13 at 21:59

Just writing DatePosted by itself might refer to a type, field, property or method group. What if it referred to a method group that, by chance, took the right type of argument? Then this would do the wrong thing.

Being explicit, sometimes, is not a bad thing. The syntax

c => c.DatePosted

means specifically a function that takes an input and returns the DatePosted field/property of that input. This is flexible -- you can write

To be more concise the lambda expression refers to an anonymous delegate which when invoked will return some output of the proper type. The point of the lambda is to encapsulate a transform over some input (i.e. a function in mathematical terms) in a concise syntax.
–
RomokuMar 7 '13 at 4:04

Mainly, because "DatePosted" has no intrinsic meaning by itself. It could be a method, a property, a type, anything. It also doesn't match the method signature of Func<TSource, TKey>, but I'm assuming you mean "if the compiler were smarter".

You can, however, pass in something that matches the signature, like so:

I think the key point is that such a feature would introduce a disturbance to the context. What is "DatePosted" and where is it defined? The compiler treats method calls in a certain way and introducing a special kind of method call would be tricky. How do we know this should be a special method call? It is simply more pragmatic to give the compiler all the context it needs. That's why the succinct lambda syntax is so helpful.