Discussion: async/iterator local function captures

[alrz]

A common use case for local functions is to avoid state machine creation in async or iterator functions before parameter validation, etc. But if you capture any variable or parameter, the corresponding fields will be added to a class that we were intended to avoid creating in the first place. The only workaround is to pass every parameter to the local function which has to have a different name.

It would be nice to generate a separate struct for captured variables in async/iterator local functions, or permit a local function to shadow outer function's parameters.

Related: #11308

[gafter]

@ljw1004 You may be interested in this.

[svick]

A simple struct wouldn't work, because the local function might modify a captured variable, which is then read by the parent method. Though this is probably not the common use case, so I think some optimizations regarding the closure allocation would be worthwhile.

[alrz]

@svick Note that this only happens when your local function is async or iterator; otherwise a struct will be passed by ref. So this is probably due to the fact that async/iterator functions cannot accept refs as parameter. Anyhow, the use case you've mentioned is 1% of the time, really, I'd never capture locals in a local function and then mutate them, that'd be a messy code, indeed. Since local functions cannot have something like capture lists, this can be a source of bugs. Currently, the best you can do is this: (even I'd like to get warnings if I accidentally capture any variables here, however it can be done via an analyzer),

public static IEnumerable<T> Where<T>(this IEnumerable<T> source, Func<T, bool> predicate) {
    if (source == null) ...
    if (predicate == null) ...
    IEnumerable<T> WhereImpl(IEnumerable<T> _source, Func<T, bool> _predicate) {
        foreach (var item in _source) {
            if (_predicate(item))
                yield return item;
        }
    }
    return WhereImpl(source, predicate);
}

Since this will be a common use case (capturing variables at callsite via parameters) I think it'd be nice to be able to use same parameter names as the outer function for the local one.

[alrz]

@gafter Can I reword this issue as a feature request to allow local function's parameters to shadow the outer method's parameter names, or is that a no-go?

[gafter]

@alrz I think repurposing this issue would be confusing. Please create a fresh feature request and include the motivating example(s).

[alrz]

@gafter Right on. It's filed over at #15793.