Proposal: Shorthand for simple expression lambdas

[HaloFour]

Copied from dotnet/roslyn#3561

This has come up a few times on CodePlex as well as here but I've not seen any formal proposal for it so I thought I'd post one just to track it and get some conversation going about it.

Many of the LINQ extension methods accept a single argument and return a value, most often the result of a simple expression stemming from that argument. In those simple cases the developer is still required to assign the parameter value to a name that cannot shadow a name used in the current scope and then immediately reference that name in the body of the closure.

var query = db.Orders
    .Where(order => order.Value > 50.0m)
    .Select(order => order.Employee)
    .OrderBy(employee => employee.Name);

I propose that a short-hand version of this common pattern where the value of the argument can be accessed through a specific sigil which must be referenced in the method body. The following uses the sigil @ and is the same as the query above:

var query = db.Orders
    .Where(@.Value > 50.0m)
    .Select(@.Employee)
    .OrderBy(@.Name);

[orthoxerox]

Where does a shorthand lambda expression begin or end?

[HaloFour]

@orthoxerox

It would be a single expression. The sigil would effectively expand out to $temp => $temp, so (@.Value > 50.0m) would be ($temp => $temp.Value > 50.0m).

I'd be curious to hear other opinions and interpretations, but I'm personally not all that interested in another full-fledged syntax for lambdas.

[iam3yal]

As I said previously I like the idea but I think that the idea can be expanded to $1.*, $2.*, $3.*, ... and then as a syntactic sugar we can have $.* as a shorthand for $1.* or even in place of it.

[WeihanLi]

I like this, @ may be difficult to use with razor page, it's conflict with razor keyword

[NMSAzulX]

This is cool!

[alrz]

@HaloFour Do you think this is necessary with method references in mind? I admit that they are more limited than something like this but I don't see how this is an improvement over proper lambdas.

[iam3yal]

@alrz I actually thought about this so thanks for bringing this up, I prefer this mostly because currently, we have to come up with letters that don't make sense or do but in many cases the variable isn't the subject and so using the position to access the object make more sense, at least to me and if it's an improvement over the current syntax then why not?

[HaloFour]

@alrz

I'd evaluate the two independently. Method references can certainly make the expressions less verbose (depending on the syntax that might be adopted), but they can only represent a narrow set of those expressions. It's fine for simple Select where you intend to extract a single property, but doesn't help with Where or OrderBy where you'd want an adhoc filter/expression.

[alrz]

@eyalsk

we have to come up with letters that don't make sense

Underscore is still an identifier and yet, not a letter. And how @ makes more sense than _?

so using the position to access the object make more sense,

Mathematica has this but conciseness often wins out the readability in that context as there is an operator for most of functions. I think, if you have more than one or two parameters, you should be using meaningful names, no?

@HaloFour

But doesn't help with Where or OrderBy where you'd want an adhoc filter/expression.

I'd prefer method references over lambda because (1) they avoid double invocation (2) they infer overloaded members (3) syntax is a nice-to-have after all. On the other hand, shorthand lambda (1) doesn't avoid double invocation because probably it's not a double invocation if you can't use method references already as you mentioned, (2) doesn't provide any advantage in terms of type inference compared to lambda expressions, they are practically the same, (3) the syntax is confusing. with any choice of token, honestly I can't imagine what language grammar you have in mind for this.

The question is, why would you want to squeeze such an expression (that is admittedly not considered straightforward) to that form? I mean, if it's already in its simplest form, we probably shouldn't try to make it simpler.™

[HaloFour]

@alrz

I don't disagree. My statement is that method references can't fit in many of these scenarios. Java has both and I use method references where possible but I'm still using simple lambda expressions the vast majority of the time.

[iam3yal]

@alrz

Underscore is still an identifier and yet, not a letter. And how @ makes more sense than _?

Well, I'm suggesting to use $<position>, however, it's not just having @ it's also eliminating the need to use the lambda operator, I mean between f((_) => _.Value) vs f(@.Value) the latter seems more attractive.

Mathematica has this but conciseness often wins out the readability in that context as there is an operator for most of functions. I think, if you have more than one or two parameters, you should be using meaningful names, no?

Well, maybe, I mean sometimes you may want to do f(($1.A+ $2.B) + $3.C) and might not care so much about the parameters.

The question is why we need to choose this feature over the other or vice-versa?

p.s. I think I need to write a different proposal about it because it's slightly different than this one, @HaloFour what do you think? I mean mine would cover yours too.

[HaloFour]

@eyalsk

My concern about such syntax is that it seems to largely intend to replace proper lambdas. I don't think that C# needs another full-fledged syntax for lambdas. It also seems like a nightmare to parse since there is no obvious place that the lambda begins. You could have a nested set of statements several levels deep and all of a sudden smack into a $ and the compiler would have to know which expression is a lambda and which positional argument is associated with which parameters.

What does the following mean? I can think of at least two perfectly valid interpretations.

f1(f2($1.A + $2.B) + $3.C)

[alrz]

Also two perfectly valid interpretations here:

f1(f2(@.A + @.B) + @.C)

[HaloFour]

@alrz

My proposal doesn't permit for the use of the sigil @ arbitrarily within the expression, only at the beginning. That eliminates such ambiguities. I would argue that if you're using the parameters in such a way that the parameter itself is important and should be named accordingly. My proposal is more about capturing the scenarios where the parameter is of virtually no importance, only the expression dotted off of the parameter is.

[orthoxerox]

@HaloFour

So 1 + @ will be parsed as 1 + x=>x?

Even with that restriction the parsing will be rather convoluted.

[alrz]

Beginning of what? @.C is also at the beginning of the RHS of the second + operator. If you're going to say "argument" I don't think that would make much sense as I don't know any other expression form that is restricted to certain contexts.

[HaloFour]

@orthoxerox @alrz

Perhaps not, but if @.Foo were to expand specifically into ($temp => $temp.Foo) then it severely limits where you can use the expression which should railroad it into the intended scenarios. Sure, you could use it outside of an argument, e.g.:

Func<Foo, string> func = @.Name;

But I think that's fine. But the expression 1 + @ would be a compiler error, just as 1 + x=>x is today despite being perfectly legal syntax.

[HaloFour]

@bellagita

Indeed, and I see zero value in having LINQ methods defining those names. item is just as pointless as arg1. It's already shorter to use a single-letter lambda argument anyway.

[alexrp]

For what it's worth, here's what Elixir does for shorthand lambdas: https://hexdocs.pm/elixir/Kernel.SpecialForms.html#&/1-anonymous-functions

In C#, perhaps that could look something like @(... reference parameters as @1, @2, ...). That would allow multi-parameter shorthand lambdas. The language could then define that parameter references of the form @n always refer to the parameters of the innermost shorthand lambda expression, eliminating ambiguity and vastly simplifying the implementation effort. That does mean you can't capture variables from an outer shorthand lambda, but I would seriously how readable such code would have been anyway; I think you should probably reach for regular lambda expressions in that case.

(In Elixir's case, nested shorthand lambdas are actually outright illegal, though I personally think it's unnecessary to go that far as long as you clearly define how parameter references work.)

So the example in the original proposal would look like this:

var query = db.Orders
    .Where(@(@1.Value > 50.0m))
    .Select(@(@1.Employee))
    .OrderBy(@(@1.Name));

Admittedly not quite as short, but it's something to consider.

[CyrusNajmabadi]

@(@1.Value > 50.0m)
i=>i.Value > 50.0m

The latter is shorter. If you have spaces, you have:

@(@1.Value > 50.0m)
i => i.Value > 50.0m

Which is only one char longer. I don't see the benefit here.

[alexrp]

Just to be clear, my previous comment was meant mainly as food for thought since multiple parameters and nesting (and the issues with those) were brought up here a while back; it wasn't meant as a counter-proposal in and of itself.

---

In the interest of fairness, it's worth pointing out that the above shorthand form would be shorter (regardless of spacing) the more lambda parameters you have, where you're using those parameters in more elaborate expressions such as member access:

x=>x.Value
@(@1.Value)

(x,y)=>x.Value+y.Value
@(@1.Value+@2.Value)

(x,y,z)=>x.Value+y.Value+z.Value
@(@1.Value+@2.Value+@3.Value)

I imagine you could simultaneously allow the form originally proposed for the probably more common case of a single lambda parameter. There's arguably some precedent for that in how lambda expressions allow you to write x => ... as a shorter form of the more general syntax (x) => ....

---

There's also another thing to consider regarding multi-parameter lambdas. This could just be a 'me' issue, but sometimes when I'm typing out lambda expressions with multiple parameters, I might only realize halfway through writing the expression itself that I forgot to declare, say, a trailing parameter in the parameter list, so I have to move the cursor back and add in the missing parameter. The advantage of the shorthand syntax here is that if you've used, say, 2 parameters in the expression and you realize you need a 3rd, you just literally type @3 and you're done. It's not just about shortening the resulting code, but also saving keystrokes by reducing repetition.

[CyrusNajmabadi]

(x,y,z)=>x.Value+y.Value+z.Value
@(@1.Value+@2.Value+@3.Value)

That seems to be almost no savings at all to me :)

[theunrepentantgeek]

In fact, the number of characters saved is exactly the number of parameters, at the cost of obfuscating the whole thing.

When I see this

(x,y,z)=>x.Value+y.Value+z.Value

I can infer from the problem domain what x, y, and z might mean ... perhaps they're 3D point coordinates? Hard to tell from a single line of code.

Quoting the OP, I can rewrite the query as this:

var query = db.Orders
    .Where(o => o.Value > 50.0m)
    .Select(o => o.Employee)
    .OrderBy(e=> e.Name);

And I don't need much insight to recognize that o means order, and e means employee.

With positional parameters like @, @1, @2, and @3 not only are they inherently meaningless, but each one might have a different meaning on each line:

var query = db.Orders
    .Where(@.Value > 50.0m)
    .Select(@.Employee)
    .OrderBy(@.Name);

The first @ is an order, the second @ is also an order, but the third @ is an employee.

Code is read many many times more often than it is written; saving a few moments of the writers time once at the cost of spending a few moments of the readers time many many times seems a Faustian bargain.

[gilmishal]

Code is read many many times more often than it is written; saving a few moments of the writers time once at the cost of spending a few moments of the readers time many many times seems a Faustian bargain.

@theunrepentantgeek
I generally agree with the issue you are raising - I do think however that with the right tooling, this issue can be solved. If in VS hovering over the @ would show which type it is, this won't be an issue really.
Just like var isn't an issue to most c# programmers anymore - and even though the recommendation was to use var when the type is obvious, vars are everywhere and it's not causing any issues for most readers, because they can just see the type.

Sure there are cases where this entire thing can be confusing and will require a little more time from the reader, but those cases are a small minority, and I like the idea of giving programmers the freedom and the responsibility of choosing the more fitting syntax.

[darrenoakey]

while I'd love this feature, can I argue for a slightly different syntax?

var query = db.Orders
    .Where( .Value > 50.0m)
    .Select( .Employee)
    .OrderBy( .Name);

I believe that having nothing in front of the "." makes it more intuitive, cleaner and easier to read?

[SageV-add123]

In contrast to several of the suggestions here, I suggest that the value contextual keyword be extended slightly to fit this use-case.

var query = db.Orders
    .Where(value.Cost > 50)
    .Select(value.Employee)
    .OrderBy(value.Name);

While not as succinct as the @ suggestion, it is in my opinion, more readable, more like English, and relies on an existing keyword instead of wholly new syntax.

[HaloFour]

I'd suggest that the problem with using any identifier here is that such code is already syntactically legal which would lead to ambiguity.

[SageV-add123]

Ahhh, true

[LWChris]

I had the same idea this morning, good to see others are having this idea, too, sad to see it got nowhere in 6 years and is seemingly dead for 1.5 years now?

Sorry if this is unwanted bumping, but I was about to post a proposal, found a similar one in the search which had been redirected here, so I thought I'd voice my opinion here. My take on everything in this thread, sorted by my agreement in ascending order:

• .Where(value.IsHighEnough): value might exist and have a method IsHighEnough(Order order) => impossible, leads to ambiguous code
• .Where(@(@1+@2+@3) > 5): totally not a fan; it looks very cluttered quite quickly, and is longer, and it doesn't even save a lot of characters in the few cases where it would
• .Where(_.Value > 50): not a good idea because _ is the discard parameter, which specifically means "I'm not using this" - using it thereafter seems counter-intuitive
• .Where(@.Value > 50): acceptable, but not ideal (see below)
• .Where(~.Value > 50): my "original" idea; I like '~' better because '@' is an optically very cluttered character itself, whereas '~' is visually light; I also thought about using ..Value but the '.' is too easy to overlook
• .Where(.Value > 50): this is my absolute favorite. It has the least cluttered appearance, it has the most characters saved, and the syntax would (in theory) still be open for positional arguments if they were introduced as @1 or something similar nonetheless.

Historically, I found the best additions to the language to be those where I can remove code instead of replacing it, for example

• m_Dict = new Dictionary<Guid, MyObject>(); becomes m_Dict = new();
• if (x == 0 || x == 3 || x == 5 || x >= 8) becomes if (x is 0 or 3 or 5 or >= 8)
• myString.Substring(startIndex, endIndex - startIndex) becomes myString[startIndex..endIndex]

I would be really great if I could write .Where(.CanWrite) instead of .Where(prop => prop.CanWrite).

[CyrusNajmabadi]

I would be really great if I could write .Where(.CanWrite)

Note: this likely conflicts with proposals we have to allow lookup of static members in contextual locations without specifying the container name. e.g. TakesConsoleColor(.Red)

[darrenoakey]

get that - although... would there actually be a conflict? I mean - you know what is being expected.... clearly the above can only work if it's getting some particular target class for you to be looking for the static members of. And you aren't going to have static methods on a delegate/functor - so basically if the parameter is of type ConsoleColor - then .Red means ConsoleColor.Red - but if the parameter is Func<string,String> then .y means x=>x.y?

[darrenoakey]

but if you don't buy that... - I'd suggest the average bit of C# code has 50 trivial lambdas for every 1 static field access - so if you can only choose one for this feature - I don't think there's many people voting for static shortcuts!

[CyrusNajmabadi]

get that - although... would there actually be a conflict?

It would certainly be exceptionally odd. The exact same syntactic structure meaning a lambda in one semantic context, but a static member lookup in another...

I'd suggest the average bit of C# code has 50 trivial lambdas for every 1 static field access

Note this goes beyond just static fields. You can imagine this for things like:

someDiscriminatedUnion switch
{
    .Case1(...) =>
    .Case2 =>
    .Case3 { ... } =>
    _ => 
}

and so on. Basically that given an inferred type location, we could use .Name off of it to access members (including nested types) of that type.

Second of all, i def don't agree with the assesment on the 50:1 lambda vs static metric.

[Korporal]

Perhaps the argument's position could be expressed as {0} or {1} and so on:

(x,y,z) => x.Value + y.Value + z.Value

Would become:

{0}.Value + {1}.Value + {2}.Value

of course one could also write

{1}.Value + {0}.Value + {2}.Value

and so on.

Where the subscript must be an integer literal.

[iam3yal]

@Korporal I've suggested a similar thing but don't think it's received well (by the LDM) and I doubt it's because of the syntax. Personally I do think it's worth doing but who knows the LDM might come up with something better. 😄

[LWChris]

Perhaps the argument's position could be expressed as {0} or {1} and so on:

(x,y,z) => x.Value + y.Value + z.Value

Would become:

{0}.Value + {1}.Value + {2}.Value

I am still weary about the whole "positional arguments" idea in general. I think it is quite rare that multiple arguments of a lambda are equal in meaning and commutable. More often, the different parameters are different things.

For example when using LINQ, there are tons of opportunities for trivial lambdas (Where, Select, Any, All, First/Last/Single(OrDefault), etc.), but all of them also have a second overload that has two parameters, argument and index. Using {0} and {1} would give you an excuse to not name two things, but when they are not commutable, that's a bad thing IMO.

Take this example:
.Select({0} > 10 ? {1} : -1)

I think it would be better to be forced to write
.Select((value, index) => value > 10 ? index : -1)

because it's easy to get confused with what {0} and {1} are.

The whole point of arguing "the name should be omittable" is that it doesn't matter what name you use, because it is the only thing you use throughout the whole expression.

.Select(x => x.Name)
.Select(p => p.Name)
.Select(person => person.Name)
.Select(emp => emp.Name)
.Select(employee => employee.Name)

It's all equally clear to me.

Second of all, i def don't agree with the assesment on the 50:1 lambda vs static metric.

I did a GitHub code search for (x => x. (no forks) and found 954k files.

Each result page has 20 entries, page 1 has 91 occurrences, page 2 has 60, page 3 has 195; makes 115 on average. 954k files means 47.7k pages, with ~100 occurrences per page that is about ~5M occurrences. ONLY for (x => x., ignoring all other parameter names, all cases where brackets or whitespace are different, and only counting each lambda, not even every time the parameter is per expression.

One thing I would like to mention though: let's not forget about the x => x lambda itself, used in .OrderBy or .ToDictionary or even .All. If we use a symbol and make that symbol mean "this is a lambda that has one parameter and every occurrence of that symbol becomes the parameter of that lambda", this would open up this feature for even more cases.

Note: I'm using ~ as symbol here, because @ is annoying since it constantly makes the mention-window pop up.

Rule: If expression contains ~ then replace it with a lambda expression of form $temp => expression, and replace every ~ in expression with $temp.

What examples from the search result would look like:

• Execute<Build>(~.Compile)
• .OrderBy(~)
• .Where(~.Length > 0)
• .ToDictionary(~, ~.Value.First())
• .Select(~.PackagePart)
• .ForEach(~.Name = $"{group.Name} - {~.Name}")
• .Sum(~.insertions)

[CyrusNajmabadi]

I'm addressing the claim that is 50:1 more common than static member lookup

[LWChris]

Might be related to that I mistyped 954k as 95400 in my calculator. 😅 It's 5M occurrences, not 500k.

And by the same logic, the "refined" search found 6.3M files. The first page contains 163 matches, that would be (now doubly checked) ~51.35M occurrences of a trivial lambdas.

[CyrusNajmabadi]

Again, that tells me nothing. It's a measure of one of your things. It has absolutely no information to indicate how that compares to static member lookup.

Furthermore, it does nothing in furtherance of the design consideration that it may be preferable to lift up two important, but distinct, areas in valuable ways, versus lifting on one in a marginal fashion (compared to what we have done so far), while leaving the other out.

[CyrusNajmabadi]

If you have any idea how to find out how often those are done,

I would use roslyn, download all the projects, load them, then analyze all the code in it to see how often each is done.

--

Note: as a point of reference. Virtually every enum would count. And that's just enums :)

[LWChris]

Okay, maybe I'm lacking the full understanding then of what constitutes a "static member lookup". Are you talking about something like this?

Color myColor;
var x = myColor switch {
  .Red => …,
  .Yellow => …,
  …
}

[tomschrot]

Kotlin has the "it" keyword for this. And it uses a tricky braces syntax.
If the only or last function parameter is a lambda, use braces like:

var query = db.Orders
    .Where    { it.Value > 50.0 }
    .Select   { it.Employee }
    .OrderBy  { it.Name };

It would be great if the lambda has only 1 parameter to "it" / "this" implicitly:

var query = db.Orders
    .Where    { Value > 50.0 }  // refers to implicit this.
    .Select   { Employee }
    .OrderBy  { Name };

and if you could declare any function with a single parameter as "infix" that allows operator-like syntax:

public infix R Where <O, T, R> (this O obj, T arg)
where O : ... 
where T : ... 
{
    ...
    return ... ;
}

that allows you to omit the braces, you get a perfect DSL

var query = db.Orders
    Where   Value > 50.0 
    Select   Employee 
    OrderBy   Name
    ;

just dreaming....

ref: https://kotlinlang.org/docs/scope-functions.html#functions

[iam3yal]

@tomschrot Kotlin has many declarative and DSL features that I really wish them to be part of C# to reduce some of the noise but the amount of design work for each feature takes time, I mean, there are features here that are pending for years.

[Korporal]

I am still weary about the whole "positional arguments" idea in general. I think it is quite rare that multiple arguments of a lambda are equal in meaning and commutable. More often, the different parameters are different things.

For example when using LINQ, there are tons of opportunities for trivial lambdas (Where, Select, Any, All, First/Last/Single(OrDefault), etc.), but all of them also have a second overload that has two parameters, argument and index. Using {0} and {1} would give you an excuse to not name two things, but when they are not commutable, that's a bad thing IMO.

Take this example: .Select({0} > 10 ? {1} : -1)

I think it would be better to be forced to write .Select((value, index) => value > 10 ? index : -1)

because it's easy to get confused with what {0} and {1} are.

Well the objective is to eliminate the need to type the (value, index) => and that means no explicit names are present. So other than their ordinal position there isn't much to play with here. One could also mistakenly write:

.Select((value, index) => index > 10 ? value: -1)

and if the types of index and value are mutually compatible, then that would compile and the developer could easily not notice.

Perhaps also, the IDE could be enhanced to that hovering over {1} enables it to display info that reveals more information about it. Or perhaps the IDE could also allow us to reformat such a lambda into either form, explicit argument names or ordinal position...

[CyrusNajmabadi]

This Syntax would likely conflict with block expressions.

[HaloFour]

Well the objective is to eliminate the need to type the (value, index) => and that means no explicit names are present.

I do not think that eliminating the need to type the names should be considered a goal of this proposal. Rather, the goal should be to allow eliding names in those cases where those names would provide no additional value. The expression should remain as legible, if not moreso, than the full lambda. To that end I question the value of attempting to extend this proposal to lambdas that accept multiple arguments, as the need to reference those arguments individually already implies that the names should have meaning.

[iam3yal]

Yes I think that multiple parameters and anything else but a single implicit parameter takes the discussion astray too, maybe I shouldn't have brought it up initially. Sorry. 😃

[darrenoakey]

I get what you are saying - but being selfish here - I have no interest whatsoever in the static thing - but use lambdas for almost everything. We have very strict rules against using enums for anything [except like calling winapi or something, where you are using someone else's code]. They lead to shotgun surgery and a proliferation of similar business rules in different parts of the code. To me - you either don't have any functionality hanging off the code, in which case an int would be fine - for instance, if you are just passing a value through from a -> b -you are far better off _not_ validating it - because then you have nothing to maintain as you add stuff... and if you do have functionality hanging off it - it's much better to use a serializer to pull it into a class - as x.MyType.RenderAsImage() is soooo much better than a function RenderAsImage( x, type ) that then does a switch on the types - because in the former, to add a new type you only have to go to one place, and you get a nice little compile assist of all the things you need to do - whereas to code the latter - you'll probably never find all the cases where you need to change - because for instance if there are five values but only one of them does X - someone will probably just say if enumValue == theValue {...}.... which is something someone else is basically guaranteed to miss when they add a new type that also has that behaviour. Bottom line - whatever may be the norm , and whatever you think of the above coding style - for us at least - any use of enums , or enum like things, or most things like switches are strictly forbidden - in fact our CI automatically fails anything with a cyclomatic complexity over 6 - which instantly disqualifies most switches. whereas lambdas and linq _abound_ - they appear everywhere I'm not in any way trying to imagine I'm particularly representative of what is out there - but I know for me at least - one feature I'd use daily - and the other almost never.

[CyrusNajmabadi]

Bottom line - whatever may be the norm , and whatever you think of the
above coding style - for us at least - any use of enums , or enum like
things, or most things like switches are strictly forbidden

We don't design for outlier cases like this. Enums are part and parcel of .net. We're also moving into that space much further with richer enum types, and things like discriminated unions. The language needs to design for the entirety of the ecosystem. :)

whereas lambdas and linq abound - they appear everywhere

Right. They appear everywhere for you because you choose that. Imagine someone coming and saying that we shouldn't invest in lambdas, because their personal niche rules disallow practically any usage of them, and they insist on avoiding them at all cost. That wouldn't be sensible on our part to cut out that large part of our ecosystem just because of the unfortunate decisions of that group. :)

[iam3yal]

@darrenoakey With all due respect but why does your religious coding style belong in this discussion?