Resolved Coroutine operates on copy of struct instead of original

Take a look at the following short script (can be tested in playmode by pressing Return/Enter):

Code (CSharp):

1. using System.Collections;
2. using UnityEngine;
3.  
4. public class Tester : MonoBehaviour
5. {
6.     private struct MutableStruct
7.     {
8.         public int mutableValue;
9.  
10.  
11.         public IEnumerator FaultyCoroutine()
12.         {
13.             mutableValue = 42;
14.             Debug.Log($"Mutable Value was changed to {mutableValue}");
15.  
16.             yield return null; // arbitrary yield
17.         }
18.     }
19.  
20.  
21.     // cached mutable struct
22.     private MutableStruct cachedStruct = new();
23.  
24.  
25.     private void Update()
26.     {
27.         if (Input.GetKeyDown(KeyCode.Return))
28.         {
29.             cachedStruct.mutableValue = 0; // reset mutable value
30.             StartCoroutine(TestRoutine());
31.         }
32.     }
33.  
34.  
35.     private IEnumerator TestRoutine()
36.     {
37.         // Expected: 0
38.         // Actual: 0
39.         Debug.Log($"Initial Value: {cachedStruct.mutableValue}");
40.  
41.         // changes the member value to 42
42.         yield return cachedStruct.FaultyCoroutine();
43.  
44.         // Expected: 42
45.         // Actual: 0
46.         Debug.Log($"Observed Value: {cachedStruct.mutableValue}");
47.     }
48. }

What I expected to happen is that the nested coroutine on line 42 operates on the cached instance of the mutable struct. Instead I can only assume that the Coroutine is executing on a copy of the instance, unlike a normal method would.
Of course this could be avoided by making

MutableStruct

a class, though this still seems like unintentional behaviour to me, or at least something worth documenting. Also, the solution of "Just make this struct a class!" can't always be applied equally well.

 

Describe it somehow decisively in points what you want to achieve. Currently, the code looks like a wrong logical use of Coroutines.

In short, if something is to set a value in an object, why use two Coroutines when one is enough.

 

Well, yes, this does not work for the simple reason how iterators work in C#. Has nothing to do with Unity. When you call a generator method that returns an iterator (IEnumerator), that IEnumerator is a compiler generated class that represents the logic / content of your method / coroutine. You can not "reference" a struct. In your case your "original" struct is probably the data stored in the field "cachedStruct" of your MonoBehaviour class. When you reach out to the struct and call the generator to create an iterator, there is absolutely no possible way that this iterator can reference that original struct that lives inside the MonoBehaviour field. For exactly the same reason, iterator / generator methods can't take ref or out parameters. Parameters to such a method (that contains a yield statement) are turned into fields of the auto-generated class. Member methods always have an implicit this parameter of the instance they belong to. Methods of structs usually receive a "ref" this pointer. Though in case of a coroutine, that's not possible in any shape or form.

So this is not a bug but simply the nature of structs and generator / iterators.

 

After some more research I can say you're absolutely right.
I tend to forget that Unity's Coroutines are not much more than a worse async/await hack that works in older .NET versions, aswell as providing the rarely used WaitForSeconds functionality. I was forced into using one because Unity hates accesses to its API from any threads other than the main one, so I'm using a Coroutine as a sort of "proxy" between an actual asynchronous operation and some functionality that has to be on the main thread (without creating a hundred state checks within a

MonoBehaviour.Update()

). I rewrote some parts of my code so the issue this post is about is of no concern anymore.
Thanks!

 

Well, the same holds true for async / await Try this struct in a plain C# project. I currently have a simply console application open and I just added this:

Code (CSharp):

1. public struct TestStruct
2. {
3.     public int val;
4.     public async Task<string> DoSomething()
5.     {
6.         val++;
7.         return "Test " + val;
8.     }
9. }

Inside another async method I just do

Code (CSharp):

1.  
2.     // in class
3.     public TestStruct s = new TestStruct()
4.  
5.     // in async method:
6.     Console.WriteLine("InitialVal: " + s.val);
7.     Console.WriteLine(await s.DoSomething());
8.     Console.WriteLine(await s.DoSomething());
9.     Console.WriteLine(await s.DoSomething());
10.     Console.WriteLine(await s.DoSomething());
11.     Console.WriteLine("FinalVal: " + s.val);

The output would be:

So as you can see, you have the same problem with async / await. In the end it works in a similar manner to normal iterators, but have much greater eco system around it (the concept of awaiters, Tasks, etc). async methods actually get also transformed into an internal iterator class or struct. Instead of IEnumerator it usually uses the IAsyncStateMachine interface. Just as with IEnumerators (methods with yield instructions), local variables and parameters of the "method" become field members of an internally generated class / struct. So even the "this" reference of the type that contains the async method has to be stored in that iterator state machine. That means that structs are copied into that iterator and therefore seperate from source.

 

Right. Makes sense! To clarify, I made some modifications to my code that completely avoided any iterator-copying-struct issues, so this whole thing is luckily not holding me back anymore. All of these behaviours are still pretty useful to know, though. Thank you for the examples!