Short-hand syntax for IEnumerable.Select

[kornelijepetak]

Starting with an example class:

class Person
{
    // ...
    public string Name { get; }
    public List<Person> Friends { get; }
}

Having an IEnumerable<Person>, we can select, for example, only Names, like this:

var names = people.Select(p => p.Name);

Also, with SelectMany, we can go further, like this:

var namesIncludingFriends = people
    .SelectMany(p => p.Friends.Select(p => p.Name))
    .Distinct();

Since Select is one of the most used operators, I was thinking about having a syntactic sugar that would work on IEnumerable<T> (maybe IQueryable<T> if possible) to shorten this kind of behaviour to:

var names = people.[Name];

or some other syntax (this is only an example).

Also, SelectMany version could be useful too, but I am not sure about the implications.

var namesIncludingFriends = people..[Friends.[Name]]

Maybe all of this is not possible and maybe useful only if a delegate used in Select is only a property access, but still it might simplify code a bit for LINQ queries.

I would like to hear both the pros and cons. Even if people find this useless, I'd like to hear it. 😄

[bondsbw]

or some other syntax (this is only an example).

I'm not sold on this syntax yet, but I do feel like this idea would improve a common scenario.

[svick]

people..[Friends.[Name]]

I find code like this unreadable. Instead, I would use query syntax, which I find much easier to understand:

from person in people
from friend in person.Friends
select friend.Name

Most code is written once and then read many times, so readability trumps saving keystrokes.

Also, one of the strengths of LINQ is that you can easily combine various operations, it's not just Select(Many). Your syntax means that if I want to add a simple Where, I have to rewrite the whole query.

[bondsbw]

@svick I disagree. I find it more readable (though the exact syntax might need some work).

Array indexing is similar. I don't think people have generally replaced customers[3] with customers.ElementAt(3), as the latter doesn't really improve readability.

[HaloFour]

customers[3] and customers.ElementAt(3) mean two very different things.

The simplest cases look alright to me, but I find people..[Friends.[Name]] to be much less readable than .SelectMany(p => p.Friends.Select(p => p.Name)).

[bondsbw]

customers[3] and customers.ElementAt(3) mean two very different things

Not sure what you mean in the context of arrays. ElementAt just calls the indexer when used on an IList<T>.

[kornelijepetak]

@svick

I follow your logic, but if something like the query continuation were not possible, then it would surely be useless, for example.

var x = people.[Name].Where(s => s.Length > 3);

Of course, my syntax is only an example, I am sure people more used to making compilers could think of a better syntax that would be easier to read.

However, I'd rather have a one-liner than write a three query sentences (in query syntax), if symbols were known to me. The same happened with null propagation operator. It's confused and not readable if you encounter it the first time, but once you know it, then the ?. suddenly means something and your mind processes it quickly. The same would happen if I knew what exactly the .[] operator does (or whichever other syntax) - with a few encounters, it'd become natural.

Also I guess with something like Roslyn/#5445, it would become unneccessary.

[HaloFour]

@bondsbw

Not sure what you mean in the context of arrays. ElementAt just calls the indexer when used on an IList<T>.

That method could call the indexer of a known interface, sure, but it can't call an arbitrary indexer. And that behavior is completely hidden from the compiler which has no concept of ElementAt. It's not like the compiler will attempt to resolve indexer syntax to an invocation of ElementAt given the lack of an actual indexer, which is in the vein of what this proposal wants to do with Select.

[bondsbw]

@HaloFour I see your point. I really only intended to make the comparison based on readability (not implementation).

I'm not sure I have a better idea than the OP for syntax. Here are a couple that come to mind:

people[#Name]

people[.Name]

[MgSam]

People already complain that LINQ chains are hard to read. This would be that 100X. Plus, we don't need a 3rd syntax for doing LINQ.

[bondsbw]

@kornelijepetak

var x = people.[Name].Where(s => s.Length > 3);

How about shorter Where syntax:

var x = people.[Name].[Length > 3];

This would take care of the exemplary cases at #91 and #602.

[svick]

@bondsbw I think that takes a bad idea and makes it much worse:

• What does people.[IsManager] mean? Both people.Select(p => p.IsManager) and people.Where(p => p.IsManager) are valid.
• The same (or very similar) syntax sometimes meaning Where and sometimes Select is a recipe for confusion.
• It has the issues that are outlined in Proposal: shorten lambdas with one argument #602 (comment) in that it's not clear whether Length > 3 means s => s.Length > 3 or s => Length > 3 (both could be valid).

[bondsbw]

What does people.[IsManager] mean? Both people.Select(p => p.IsManager) and people.Where(p => p.IsManager) are valid.
The same (or very similar) syntax sometimes meaning Where and sometimes Select is a recipe for confusion.

Good points. This will require at least a subtly different syntax, I'm open to ideas. (people[#IsSelected] vs people[.IsSelected]?)

It has the issues that are outlined in #602 (comment) in that it's not clear whether Length > 3 means s => s.Length > 3 or s => Length > 3 (both could be valid).

I think I might prefer the syntax people[.Name], which extended here could be along the lines of people[.Name][.Length > 3]. I don't believe there is any ambiguity (other than your first points).