Why does this MSDN example for Func<> delegate have a superfluous Select() call?

Question

The MSDN gives this code example in the article on the Func Generic Delegate:

Func<String, int, bool> predicate = ( str, index) => str.Length == index;

String[] words = { "orange", "apple", "Article", "elephant", "star", "and" };
IEnumerable<String> aWords = words.Where(predicate).Select(str => str);

foreach (String word in aWords)
    Console.WriteLine(word);

I understand what all this is doing. What I don't understand is the

Select(str => str)

bit. Surely that's not needed? If you leave it out and just have

IEnumerable<String> aWords = words.Where(predicate);

then you still get an IEnumerable back that contains the same results, and the code prints the same thing.

Am I missing something, or is the example misleading?

Answer 1

The Select is indeed redundant.

I suspect that this example may have been "translated" from the query comprehension syntax, as in:

IEnumerable<String> aWords = 
    from w in words
    where (...)
    select w;

When using this syntax, you have to select at the end, it's just how the compiler works. When using the Where extension method, however, it's completely unnecessary unless you actually need to do a separate projection.

Or, maybe it's just a mistake. The MSDN writers aren't infallible!

Answer 2

No it's not needed.

Such a construct could be used if you wanted to force a sequence to be lazily evaluated i.e. to prevent casting. If you had a method that returned a List<T> but declared an IEnumerable<T> return type then a client could cast the return type and manipulate the underlying list directly. Obviously this is a very bad idea, but a class could protect its state by applying an identity select such as the one used in this example:

public IEnumerable<T> Items
{
   get { return privateList.Select(i => i); }
}