C# compiler should be able to determine a variable being set within an awaited lambda

[jez9999]

I have some code where I'm assigning a reference-type variable inside an awaited lambda, like this:

private class TestClass {
    public int TestInt;
}

public async Task TestMethod() {
    TestClass testVar;

    await Task.Run(() => {
        testVar = new();
    });

    var testInt = testVar.TestInt;
}

But the last line gives me "Use of unassigned local variable 'testVar'". It seems that the C# compiler is still unable to determine that a variable is guaranteed to be set in an awaited lambda. Is there any technical reason for this? I know I can use = null! to override this warning but it seems to me that the compiler should be able to figure it out.

[HaloFour]

It seems that the C# compiler is still unable to determine that a variable is guaranteed to be set in an awaited lambda.

C# has no concept of what Task.Run is or does or what the relationship it has with the lambda that you passed to it.

[jez9999]

Yeah, but why shouldn't it? It should know that an await will run the task before continuation.

[HaloFour]

It knows that the Task returned from Task.Run is awaited, but it has no idea that the lambda you passed has anything to do with that task. C# doesn't make assumptions as to what arbitrary methods in the BCL do.

[jez9999]

So my best workaround is to initialize with = null!?

[HaloFour]

There is an overload of Task.Run that accepts a Func<T> and returns a Task<T>, I would recommend using that instead. That way you can await on the result of the task.

TestClass testVar = await Task.Run(() => new TestClass());

[jez9999]

The Task.Run was just an example; in reality I'm using a method that executes a lambda by task completion but the task doesn't return a value.

[TahirAhmadov]

See #4187

[theunrepentantgeek]

Don't conflate the two.

Lots of the responses saying "that's a bad idea" were from folks quite happy to see C# changed by adoption of good ideas.

[333fred]

Well, the issue is more that mustcall doesn't really work here. Sure, Task.Run will eventually call the lambda, but you can only be assured that it ran after it's been awaited, which basically means that we're back to the same problem as you had originally.

[TahirAhmadov]

Yes, the challenge here is twofold: 1, somehow tell C# that the delegate will be invoked - which mustcall aims to address - and 2, deal with the async/await - it would have to be something like mustcall await, and even then the returned task-like object has to be awaited and not saved to a local/etc.

async Task Foo(mustcall await Func<Task> action)
{
  // do something else
  await action(); // OK
  // do something else
}
async Task Foo(mustcall await Func<Task> action)
{
  // do something else
  var task = action();
  // do something else
  await task; // OK? this is difficult
}
async Task Bar(mustcall await Func<Task> action)
{
  // do something else
  _ = action(); // error: delegate invocation not awaited
  // do something else
}
async Task Bar(mustcall await Func<Task> action)
{
  // do something else
  if(...)
    await action(); // error: delegate invocation not in unconditional execution path
  // do something else
}

int x;
await Foo(async () => { x = 5; });
Console.Write(x); // OK

int y;
var task = Foo(async () => { y = 5; });
Console.Write(y); // error
await task;
Console.Write(y); // OK? this is difficult

[HaloFour]

IMO the workarounds for this are trivial, don't depend on mutating side effects to affect definite assignment of shared state.

[theunrepentantgeek]

I agree - this is rapidly turning into something where the proposed solution is significantly worse than the original problem.