Proposal: implicit lambda parameter if body is a property access

[kornelijepetak]

I guess this is just wishful thinking, but something like this would improve readability in many cases (although may be confusing if unaware of the feature):

Suppose we have a class

public class User 
{
  public int Id { get; set; }
  public string FullName { get; set; }
  public DateTime DateOfBirth { get; set; }
  public int Group { get; set; }
}

And then with LINQ we usually do something like this:

IEnumerable<User> users = // ...get users

var names = users
  .OrderBy(u => u.Group)
  .ThenBy(u => u.DateOfBirth)
  .Select(u => u.FullName)
  .ToList();

var namesMap = users
  .ToDictionary(u => u.Id, u => u.FullName);

All lambdas here are simply property access. What if we could do it like this?

var names = users
  .OrderBy(Group)
  .ThenBy(DateOfBirth)
  .Select(FullName)
  .ToList();

var namesMap = users
  .ToDictionary(Id, FullName);

It would of course use implicitly-parameterized lambda only if there are no other suitable candidates for the identifier in the given context. For example, if there's a function in scope called Group that would match the signature, it would have to be chosen before using implicitly-parameterized lambdas, I guess.

I am also probably not seeing lots of semantic difficulties here and I am aware that it's probably too much work for such a small benefit and maybe it's even impossible to integrate into C# grammar, but I would still like to hear some insight? Would you consider it useful? Is it hard to implement? What would be the gotchas?

[dsaf]

Method group syntax for getters/setters basically:

http://stackoverflow.com/questions/886822/what-is-a-method-group-in-c
http://stackoverflow.com/questions/6988730/convert-to-method-group-resharper

[alrz]

Related: #5444

[HalidCisse]

How about this

var names = users
.OrderBy(.Group)
.ThenBy(.DateOfBirth)
.Select(.FullName)
.ToList();

var namesMap = users
.ToDictionary(.Id, .FullName);

[timgoodman]

I like the readability of this, if it can be made to work. But would DateOfBirth (or .DateOfBirth) only be interpreted as a lambda if it's the argument to a function that takes a lambda? I think this might make overload resolution tricky (especially where one overload takes a lambda argument and another takes a non-lambda argument). Normally the compiler chooses the best overload based on the type of the arguments, but in this case the type of the arguments seems to be determined by the choice of overload.

Maybe as an alternative we could have a less-verbose syntax for simple lambdas. In Scala, you can say _.DateOfBirth instead of x => x.DateOfBirth. In Swift, I believe you can do $0.DateOfBirth (referring to arguments by their position in the parameter list: $0, $1, $2, ...). Either of those feels more readable and less needlessly verbose than x => x.DateOfBirth.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

I have not moved this feature request to the csharplang repo because I don't believe it is something we are likely to ever do, due to the required changes in the name lookup algorithm that would likely be a breaking change, and due to the lack of significant improvement to expressiveness. However, you are welcome to move discussion to the new repo if this still interests you.