Interesting difference between delegates and local functions

[paulomorgado]

Preparing for C# 7 while coding in C# 6, I decided that it was good enough to use some delegates for now in order to have the code prepared for C# 7 local functions in the near future.

I wrote something like this:

async Task DelegatesMethod(List<List<int>> listOfLists)
{
    var listOfTasks = new List<Task>();

    foreach (var list in listOfLists)
    {
        lock (listOfTasks)
        {
            Func<Task> f1 = async () =>
            {
                await Task.Yield();
            };

            listOfTasks.Add(f1());
        }
    }
}

That would be, in the future, converted to:

void LocalFunctionsMethod(List<List<int>> listOfLists)
{
    var listOfTasks = new List<Task>();

    foreach (var list in listOfLists)
    {
        lock (listOfTasks)
        {
            async Task f1()
            {
                await Task.Yield(); // CS1996: Cannot await in the body of a lock statement
            };

            listOfTasks.Add(f1());
        }
    }
}

Except that I now get a CS1996 error.

But this compiles:

void LocalFunctionsMethod(List<List<int>> listOfLists)
{
    var listOfTasks = new List<Task>();

    foreach (var list in listOfLists)
    {
        lock (listOfTasks)
        {
            listOfTasks.Add(f1());
        }

        async Task f1()
        {
            await Task.Yield();
            var l = list;
        };
    }
}

/cc @MadsTorgersen @gafter

[wanton7]

I listened a some podcast I can't remember from where, but it said local functions use some sort of black magic so avoid allocations do inlining etc. they are not same as Func<Task>.
Might have been this https://channel9.msdn.com/Blogs/Seth-Juarez/Whats-new-in-C-70-with-Mads-Torgersen local function discussion starts at 19 minutes.

Also as an side note you should always keep lock scope small as possible anyway. You shouldn't be creating Func<Task> or do anything that you don't need inside a lock scope that doesn't need a lock, it will degrade multi-threaded performance.

[paulomorgado]

I don't think the C# compiler inlines functions. Does it? It's the JIT compiler that inlines small functions.

But moving the function definition does not change "inlinability" or the scope of the lock. And it compiles.

[svick]

@wanton7

local functions use some sort of black magic so avoid allocations do inlining etc. they are not same as Func<Task>

It's true that local functions avoid allocations by sometimes using a struct (passed by ref) for their closure and that they can be inlined by the JIT, because they are called directly, not through a delegate.

But I don't see how is any of that relevant here.

[wanton7]

@svick Your are probably right and issue is probably that roslyn's await lock check doesn't understand local functions.

[alrz]

Local function doesn't use ExecutableCodeBinder, it binds the body "in the context" hence it still thinks that await is in a lock. I think that's probably it. EDIT: but using it causes additional errors to be produced that are not applicable to lambdas, like "return expected" in an iterator local function so perhaps it should be special cased?

[paulomorgado]

Nevertheless, no code under the lock is being awaited. It's just being defined and not closing over the locked object. And that would be, at most, a concurrency problem.

[alrz]

@paulomorgado

yield is not allowed in finally (just local functions since we don't have iterator lambdas)

finally {
  IEnuemrable<int> Local() {
    yield return 1; // ERROR
  }
}

or await in unsafe (in both cases),

unsafe {
  Func<Task> f = async () => await Task.Yield(); // ERROR
  Task Local() => await Task.Yield(); // ERROR
}

so there might be a good reason for that, but since your example does compile with a lambda I suspect it's a bug.

[jnm2]

This looks like a https://github.com/dotnet/roslyn bug.

[MadsTorgersen]

Agree that this looks like a bug.

[paulomorgado]

@MadsTorgersen,

A compiler bug or a spec bug?

[gafter]

This compiler bug has been reported at dotnet/roslyn#18644