Runtime: Adding "state" arguments to LINQ.

[SamuelEnglard]

Motivation

Very often when using LINQ the compiler has to capture variables for us, with all the crazy compiler magic that comes with that (Generated classes, memory allocations, extended life, etc). Most of the time it's only one variable that needs to be captured so the cost of the magic isn't worth it.

Proposal

Adding LINQ methods that take a "state" argument to pass into the operating functions. I'll only give one example here instead of listing EVERY API that would need to be added. If the idea is green lighted I'll create such a list.

namespace System.Linq
{
    public static class Enumerable
    {
+        public static bool Any<TSource, TState>(this IEnumerable<TSource> source, TState state, Func<TSource, TState, bool> predicate);
    }
}

Issues

Admittedly it is a large change for a limited amount of gain.

[karelz]

The compiler magic already exists. We would pollute the API surface with lots of new API overalds and we would make it harder for developers to choose which overload to use for very little benefit.
Also usage would have harder time to "add one more variable" - I am afraid that Tuples would be passed instead, making the overall code more unreadable.

Linq in general is IMO not about super-top performance, but about convenience and ease-of-use.
I don't think this API is a good idea.

[SamuelEnglard]

We could mark the functions as "Advanced" for Intellisense? I do agree with your concerns though.

[karelz]

What do you mean by "Advanced for Intellisense"? Is there an existing concept? Or are you proposing a new one? Where do you draw the line what is Advanced and what is not?

[davidfowl]

We just need stack allocated closures... 😄

[borgdylan]

@davidfowl That wouldn't happen easily because its a CLR level change. AFAIK both localloc and newobj allocate on the heap. It would be nice is the CLR actually had stack allocation in terms of an op-code.

[SamuelEnglard]

@karelz I'm referring to https://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute(v=vs.110).aspx

[karelz]

@SamuelEnglard oh, you meant always hide it and never show it to any user. Discoverability of such API is very poor -- we use it only for APIs which we want to obsolete, but have to keep around for source code/binary compatibility. The idea is an API with this attribute is on its way to extinction.

[SamuelEnglard]

@karelz I mean to set it to Advanced so most users don't see it.

[jnm2]

ReSharper intellisense totally ignores both EditorBrowsableState.Advanced and EditorBrowsableState.Never.
IIRC Visual Studio's C# intellisense totally ignores EditorBrowsableState.Advanced.

[SamuelEnglard]

ReSharper totally ignores both EditorBrowsableState.Advanced and EditorBrowsableState.Never.

That explains a lot....

IIRC Visual Studio's C# editor totally ignores EditorBrowsableState.Advanced.

By default it does, but that can be changed.

[karelz]

By default it does, but that can be changed.

I don't think it is worth the trouble. If we have plenty of such examples, we can reconsider in future.
I would suggest to close this issue ... any strong objections?

[OmarTawfik]

Agreeing with @karelz. Closing this until further news.