How to deal with side effects produced by async/await when it comes to mutable value types?

Question

Please, consider the following example code:

using System.Diagnostics;
using System.Threading.Tasks;

public struct AStruct
{
    public int Value;

    public async Task SetValueAsync()
    {
        Value = await Task.Run(() => 1);
    }
    public void SetValue()
    {
        Value = 1;
    }
}

class Program
{
    static void Main(string[] args)
    {
        Test(new AStruct());
        TestAsync(new AStruct()).Wait();
    }

    private static async Task TestAsync(AStruct x)
    {
        Debug.Assert(x.Value == 0);
        await x.SetValueAsync();
        Debug.Assert(x.Value == 0);
    }

    private static void Test(AStruct x)
    {
        Debug.Assert(x.Value == 0);
        x.SetValue();
        Debug.Assert(x.Value == 1);
    }
}

Notice the difference between Test and TestAsync. This code satisfies all the assertions.

I guess looking at the code with Reflector will tell me why, but still this is something I did not expect at all.

Of course, changing AStruct to be a class instead of a struct does fail the second assertion in TestAsync - as I would expect it in the first place.

My question is this - besides not using mutable structs with async/await is there an elegant way to make them coexist peacefully?

Mutating a value type when it is a parameter (without `ref`) is totally nonsensical. Async does not even come into this picture. — leppie, Jul 17 '14 at 18:51
@leppie The issue is that `SetValueAsync` doesn't mutate the variable that calls it, and it doesn't do so precisely because it's an `async` method. The fact that it's called on a variable that's a parameter that's not passed by `ref` isn't relevant at all. The mutation fails to even mutate the copy that `TestAsync` makes of the struct created in `Main`. — Servy, Jul 17 '14 at 19:01
@Servy: Guess the same will go for a generator (and probably when using it a free variable). — leppie, Jul 17 '14 at 19:04
[Mutable value types are evil](http://blogs.msdn.com/b/ericlippert/archive/2008/05/14/mutating-readonly-structs.aspx) - regardless of whether you're using `async`/`await`. Also, asynchronous code is inherently functional, so dealing with side effects at all is a bit awkward (it's usually cleaner to *return* a composite result instead of having the `async` method *update* values as a side effect). — Stephen Cleary, Jul 18 '14 at 00:23

score 10 · Accepted Answer · answered Jul 17 '14 at 19:14

It's inherently impossible for an async method of a struct to mutate "itself".

This of course makes complete sense when you think about it. By the time the whatever tasks you await inside of that struct actually finish, given that you've returned to the caller and allowed them to continue on doing all sorts of things, you have no way of ensuring that the actual struct instance that called the method even exists any more. If SetValueAsync was called on a local variable by a method that didn't await it or Wait on it or anything like that then that local variable's lifetime will likely have ended by the time SetValueAsync reaches the continuation of it's call to Run. It can't mutate the variable who's lifetime may or may not be in scope. The only option here is for async methods of a struct to effectively copy themselves when the method is called and have the code in the continuation reference an entirely different variable that the variable that called the async. Since the method is making a copy that won't be accessible anywhere other than the body of this async method, it means that, for all intents an purposes, an async method of a struct can never mutate that struct (and have the mutation be visible by anyone else).

You can have an async method of a mutable struct, so long as that method itself isn't expected to mutate the struct. That one method will need to return a Task<T> with a new struct, or something equivalent.

As an interesting tanget, it's within the bounds of technical possibility for an async method of a struct to mutate itself before the first await of the method if it really wanted to. The compiler chooses to take the copy right away, so this isn't actually possible, but the explicit choice was made to make the copy at the very start of the method rather than only after the first await. This is probably for the best, whether it was an intentional decision or not, as it would be super confusing otherwise.

How to deal with side effects produced by async/await when it comes to mutable value types?

1 Answers1

Linked