Is List.ForEach technically a part of LINQ or not?

Question

Currently to me, LINQ is just a loose and amorphous cloud of concepts, usually about data access but also in combination with lambda expressions, delegates, anonymous functions and extension methods, it is about string and collection manipulation, so I want to pin it down.

When I write the following code, can I say I am "using LINQ" or not?

List<string> words = new List<string>() { "one", "two", "three" };
words.ForEach(word => Console.WriteLine(word.ToUpper()));

e.g. the "ForEach" method is widely referred to as a "LINQ method" yet its home is in System.Collections.Generic.List and not System.Linq.

Answer 1

If you are trying to justify LINQ as a resume keyword, probably no. But that feature was added witht eh rest of the Linq functionality, and is in the same family of functionality, so sortof :)

Answer 2

It's not part of LINQ - it existed in .NET 2.0, well before LINQ. It's LINQ-like, but I wouldn't say it's part of LINQ.

On the other hand, if you implement your own IEnumerable<T> extension method ForEach (like in MoreLINQ) that could be regarded as a non-standard LINQ operator...

Answer 3

ForEach is not LINQ, it's just a method that takes a delegate. Been there since .NET 2.0.

Answer 4

In the example you posted, you aren't using LINQ. The ForEach method is just a nice way to iterate over the items in your enumerable datatype without explicitly writing the loop.

Answer 5

Taking a delegate does not make it LINQ.

Foreach is not a "LINQ" method, it is not a member of Enumerable or Queryable, and there is no comprehension syntax for it.

And, most of all, it modifies the source (list), which is not something LINQ to Objects does.

I would say "No".

Answer 6

Linq means "language integrated query". To really be "using" linq, you need a construct something like this:

var result = from word in words
                 where word.Length < 5
                 select word;

That said, the system of IEnumerable + lazy evaluation + lamdba expression + closures on which linq depends on is significant enough by itself to warrant it's own buzzword. Saying that you can use lambda expressions doesn't really cut it, imo. Case in point is this sample. You could use linq, but why when this is just as nice and much shorter:

var result = words.Where(w => w.Length < 5);