Should I not use LINQ to objects because Microsoft might change it?

Question

I got into an argument with a co-worker about the use of LINQ to Objects (IEnumerable, not IQueryable) in our C# code. I was using LINQ, and he said that we shouldn't be using an external vendor's (Microsoft) code in our code, but that we should wrap it ourselves in our own layer of abstraction.

Now I understand this methodology for use where you've got a no-name third party dll that may go out of business next week, or when your dealing with database calls (ie. returning a common data provider, rather than a SQL or Oracle specific one), but in my mind the LINQ syntax is too pretty/elegant/readable for Microsoft to abandon in the next 10 years. It's about as likely to be dropped as the ToString("Hello {0}", firstName); functionality.

I could give up arguing, and implement our own LINQ library that calls the standard LINQ methods under the covers, but isn't this over doing it? Plus I could only use the extension methods, I have no idea how to be able to wrap this:

from e in employees
select new { e.Name, e.Id };

What would your argument be, for or against using LINQ to objects (the IEnumerable extension methods)?

Answer 1

Your friend is wrong. LINQ was the flagship feature of C# 3.0, and will not be leaving the language. There's always a chance MS will cease to support C# (though I severely doubt that,) but as long as there's a C#, there will be LINQ.

Also, consider in which assembly the LINQ-to-objects extension methods are housed: System.Core.