Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[C# Feature] Make LINQ query syntax less dependent on LINQ method syntax #1937

Closed
dsaf opened this issue Apr 13, 2015 · 2 comments
Closed

[C# Feature] Make LINQ query syntax less dependent on LINQ method syntax #1937

dsaf opened this issue Apr 13, 2015 · 2 comments
Labels
Area-Language Design Resolution-Duplicate The described behavior is tracked in another issue Verified

Comments

@dsaf
Copy link

dsaf commented Apr 13, 2015

Currently:

return (from item in someSource
        where item.Name == "Dude"
        select item).FirstOrDefault();

Suggested version - inferring a method group:

return from item in someSource
       where item.Name == "Dude"
       select FirstOrDefault;

Supporting opinions:

http://stackoverflow.com/a/214610/486561

As soon as I have to add (parentheses) and .MethodCalls(), I change.

http://stackoverflow.com/a/279738/486561

One advantage to using the extension methods is that you can define your own and it will still read fine

@svick
Copy link
Contributor

svick commented Apr 13, 2015

I do think that a similar feature should exist, but I don't like this specific syntax, because it means it's not clear what you're selecting.

Consider:

from department in departments
from employee in department.Employees
select FirstOrDefault

What should this return? Right now, a LINQ query always clearly says what object is returned. You're proposing to change that principle. A logical extension of your proposal would be to also allow queries that have no select, like:

from department in departments
from employee in department.Employees

I don't think such query reads well and the same applies to your query.

Also, the general idea is a duplicate of #100.

@dsaf
Copy link
Author

dsaf commented Apr 13, 2015

@svick Yeah, it's a duplicate.

@dsaf dsaf closed this as completed Apr 13, 2015
@gafter gafter added Resolution-Duplicate The described behavior is tracked in another issue Area-Language Design labels Apr 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Language Design Resolution-Duplicate The described behavior is tracked in another issue Verified
Projects
None yet
Development

No branches or pull requests

4 participants