Looks nice. A lot of people don’t realize how expensive Linq can be. That said, my preference for most (source) codegen is in the editor – this would be nice as an editor plugin.

Oh, and a question – is the generated code actually semantically identical? For most uses practical uses, it is, but I think under racy conditions it could give different results.

It is, for the example. But it only works because it is known at that point that the input is not just an IEnumerable<int>, but rather an int[]. Knowing that they can generate a for loop, which is quite a bit faster than the enumerator. For an unknown IEnumerable they can still emit the loop and static helper method and cut down on the generated closure, but they cannot remove the IEnumerator usage. They could probably do the same as for the array if it's known that the source IEnumerable is a List<T> (and not a subclass, because GetEnumerator may have been overridden with side-effects).

Effectively this transformation is the same as doing "Convert LINQ to code" and "Extract method" in R# (although those tend to sometimes be unable to codify even simple LINQ expressions).

>It is, for the example.

It doesn't even look right for the example. This line:

    num += num2 + 3;

Should be:

    num += _linqitems[i] + 3;

They probably manually inlined a line like

    int num2 = _linqitems[i];

from the decompiled output. I'm fairly certain that if the transformation wouldn't result in compiling code, the compiler would refuse to compile it, resulting in no assembly to decompile. They also noted somewhere to have run the System.Linq tests and only one edge case involving Min/Max and NaN failed. Tests likely wouldn't run either if the code didn't compile.

Yeah, what the hell? That wont even compile. Is this thing even real? Why wouldn't the just use the actual output of their tool?

It's just a typo on the README and it's been fixed now.

The tool works fine, I've tried it out myself

Ok, good. A thing like that doesn't inspire confidence, but presumably it was just a typo then.

It's true, but 95% of the cases you get much better results by using the right data structures (dictionaries) instead of transforming queries to loops. Still is a very cool thing, hopefully is standardized into Roslyn

Using the best structure is a good idea but simple LINQ is very readable if performance isn't a big concern.

BTW I cover this in my recent book: https://www.packtpub.com/mapt/book/Application%20Development...

You could try code samples and benchmarks: https://github.com/PacktPublishing/ASP.NET-Core-1.0-High-Per...

How would the provided example be better realized as a dictionary?

All true, but the example is a demo that doesn't do anything useful, and not typical code.

Worth bearing in mind that this only helps if you are using LINQ against in-memory objects (i.e. LINQ to Objects). Depending on how this detects IQueryable providers it will either skip it, break it or worse of all silently 'work' but pull all the remote data into memory for evaluation. I'm hoping it's skip.

This project only works with IEnumerable, not IQueryable, see https://github.com/antiufo/roslyn-linq-rewrite/blob/09216a3b... for instance.

I guess this is for exactly the reasons you talk about, i.e. once it's working with Expression tress too much is unknown and any optimisations would be v. risky.

Looks cool!

> No support for F#

Why is this? Is it a macro (as opposed to working with bytecode directly)?

Because Roslyn[1] itself can only understand C# and VB.NET.

[1] `The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs.` - https://github.com/dotnet/roslyn

It would be more interesting to apply it selectively to LINQ on hot code paths and keep LINQ's readability where performance and allocations are not a concern

If this happens as a step during each compilation then you probably do keep readability of the input source code.

Sure, but when you start debugging you will see something else happening than what is in the input source code.

If only C# had LISP-style macros... .