I've seen LINQ lazy evaluation causing problems before, but mostly in the context of unit tests (where some code under test was simply never invoked, despite code coverage statistics looking OK).
It's clear that lambdas can be confusing to both humans and tooling, and fixing the latter seems the most viable. Visual Studio greying out LINQ lambda code that isn't reachable given current invocation patterns would be a nice start, and doesn't seem unfeasible to me given the kind of code analysis already done...
LINQ is so simple! I don’t understand how people can produce OOP monster hierarchies with mutating references all over but LINQ stumps them. You’re right that this is common, however.
LINQ is simple, but it represents a way of thinking about computation that is wildly different from what has historically been available on popular programming languages, and interacts poorly with how most people are taught to program.
I see the same thing when teaching people to program for Apache Spark (which took inspiration from DryadLINQ). They keep wanting to do things in an imperative way. It typically results in unnecessarily complicated code, and it always interacts terribly with the computational model. But it's also the way they've been conditioned to think over years or decades, and, from what I've seen, is often so deeply baked into their thought process that doing it any other way is, at best, deeply uncomfortable.
AFAIK Rider -usually- does a good job of squiggle-warning anything that will result in multiple enumeration of an unknown IEnumerable at least.
This is in fact important for two reasons:
1. General inefficiencies as mentioned.
2. There are plenty of `IEnumerable` things out there that -cannot- be repeatedly enumerated. Not the majority, but enough that you can run into day-to-day.
It's clear that lambdas can be confusing to both humans and tooling, and fixing the latter seems the most viable. Visual Studio greying out LINQ lambda code that isn't reachable given current invocation patterns would be a nice start, and doesn't seem unfeasible to me given the kind of code analysis already done...