Trivial Projections Are (Usually) Optimized Away

re: Trivial Projections Are (Usually) Optimized Away

jonskeet — Mon, 12 May 2008 21:53:02 GMT

I think the spec is actually reasonably clear on what happens - although as I've argued before, it makes it even more sensible to be able to omit the select clause - but I'm still not quite as clear in my mind about why the identity relationship is such a bad thing.

I suspect it's because I haven't seen any examples of where it would make a difference. Do you have any compelling examples where it would be really obviously a bad thing to do? I think I understand it from a "philosophical" point of view, but I can't immediately see an urgent practical problem.

re: Trivial Projections Are (Usually) Optimized Away

Eric Lippert — Mon, 12 May 2008 22:49:23 GMT

Consider the code I blogged about here:

http://blogs.msdn.com/ericlippert/archive/2008/03/28/why-can-t-i-access-a-protected-member-from-a-derived-class-part-two-why-can-i.aspx

The code requires that the private hashset only be accessed via the read-only IEnumerable<T> enumerator. If external code can get at the underlying hash set via a cast, then it can muck up the carefully maintained invariants of the class. That's why even though the collection implements IEnumerable, I had the code explicitly implement an iterator, to protect the mutable collection from undesired mutation.

You could imagine implementing the iterator as a degenerate query rather than an iterator block; we would want the result to be the same. The degenerate query should protect the mutable collection from mutation.

re: Trivial Projections Are (Usually) Optimized Away

jonskeet — Tue, 13 May 2008 00:25:29 GMT

Right, I suppose the important part is when you're returning the result of a query to another piece of code. That's quite possibly what I'd been missing before. Thanks for bearing with me :)

Obviously the code which is *doing* the query to start with already has the original reference - I hadn't been widening my mental scope far enough.

Just as a though, it would be nice to have an extension method on IEnumerable which explicitly does a "no-op select" to avoid having to write the yield return loop you had in the linked post. Easy to do, obviously, but it would be nice to have it in the framework. Maybe not for 3.5 SP1 though ;)

Jon

re: Trivial Projections Are (Usually) Optimized Away

DRBlaise — Wed, 14 May 2008 15:38:18 GMT

Eric,

I just wanted to let you know how much I have enjoyed your last several posts. Every one of your posts seems to have little seed of useful insight!

re: Trivial Projections Are (Usually) Optimized Away

Eric Lippert — Wed, 14 May 2008 16:23:43 GMT

Thanks!

re: Trivial Projections Are (Usually) Optimized Away

Bahador — Wed, 14 May 2008 21:23:43 GMT

Ummm. I didn't know about that (and I my mind crashed on those seemingly contradictory statements from spec :D).

Thanks!

3.0 is the first version of C# that I haven't read its spec fully... yet!

VCS Team Links for May 22, 2008

Charlie Calvert's Community Blog — Thu, 22 May 2008 22:12:32 GMT

Rather than place the links to the most recent C# team content directly in Community Convergence , I

re: Trivial Projections Are (Usually) Optimized Away

David Schmitt — Sat, 10 Oct 2009 07:53:41 GMT

"This is important because the collection might be a mutable collection. One does not expect that the result of a query over that collection could be used to mutate the collection! The query results should be read-only."

Another argument why it's a shame that .net doesn't support immutable datastructures out of the box. LINQ to objects would have much more latitude in optimizing queries against such things.