[batou]

I understand LINQ very well (right down to code generation and expression trees) but unfortunately I work with a lot of other people's code.

Perhaps that is the problem? :-)

More seriously, the thing has really leaky abstraction boundaries which is a main pain point. I have to write and manage a lot of boring enterprise code and creativity and expressiveness go a long way to introducing a lot of additional work.

[nlawalker]

LINQ is not where the leaky abstraction is, IEnumerable is. IEnumerable makes virtually no guarantees about anything, including order, finiteness, side effects and speed/efficiency.

This is actually one of the main reasons that the BCL team introduced the IReadOnlyXXX<> interfaces - over the years, many .NET developers trying to do the right thing and express intent in their code had taken to using IEnumerable<> in method signatures to signify that the method would not modify the list/collection... but an IEnumerable doesn't have to be a list/collection, it can be infinite! In trying to do the right thing and be expressive with intent, lots and lots of people were unwittingly losing the expression of another (very important) assumption.

Any time you are wrangling any kind of enumerable in code, you have to think about its guarantees and assumptions. LINQ's expressiveness might make it easier to forget this but it's still the rule - if I hand you a "malicious IEnumerable", it doesn't matter if you use LINQ or a couple of foreach loops, it's going to launch the missiles on every call to MoveNext() regardless.

If you are trying to express intent in your code, IEnumerable is almost never what you want to use.