why readonly field whose type is struct generates ldloca instead of ldflda ?

[leandromoh]

A have a struct type Core

struct Core
{
   public Core() => i = 0;
   public int i; 
   public void Inc() { i++;  }
}

that is a readonly field inside another type Foo

class Foo
{
   public Foo()
   {
     j = 0;   
     core = new Core();
   }
    
   public int j;  
   public int i => core.i;
   public readonly Core core;
     
   public void Inc() 
   { 
       j++; 
       core.Inc(); 
   }
}

whoever when I ran the following code the result was different of the expected

var main = new Foo();
Do();
Do();
Do();

void Do()
{
    main.Inc();
    Console.WriteLine(main.i);
    Console.WriteLine(main.j);
}

produces

0
1
0
2
0
3

instead of

1
1
2
2
3
3

I notice that problem is resolved wether

• change the type of Core from struct to class or
• maintains it as struct but removes the readonly from field

analysing the IL code I notice that when it is a readonly field (struct) the compiler generates

ldfld valuetype Core Foo::core 
stloc.0
ldloca.s 0

to find the value of a field, load its content and assign it to a local variable it declates by itself, thus making a copy of the field in its initial state (voilà!) and use the copy, so the field value is keeped untouchable each time the method Foo.Inc is called.

if I remove the readonly of the struct field the compiler just generates

ldflda valuetype Core Foo::core

to find the address of a field and use it, therefore the field has its state changed through the method calls.

ok, thats answer how the program is producing this ouput. the question now is why? why the C# compiler makes a defensive copy when the field is readonly and field is a struct? compiler already guarantees that I can not re-assign the field so I cant see no reason for this.

As final test to check if it could be some IL limitation, I ran IL directly keeping both initonly for the field and ldflda in the same program and everything cloud works fine.

complete code (sharplab)

IL program using initonly and ldflda (sharplab)

[Clockwork-Muse]

compiler already guarantees that I can not re-assign the field so I cant see no reason for this.

You are reassigning the field, though.
Keep in mind that structs are value types, and aren't stored on the heap - their data is folded into their containing field in their containing type. Unlike with a class, where the address of the heap storage wouldn't be reassignable (but the contents could be.

why the C# compiler makes a defensive copy when the field is a readonly struct?

You don't have a readonly struct - you'd have to define it on the struct itself (public readonly struct). Keep in mind that the standard recommendation and practice is to use read-only structs because they are value types, and mutating them can cause odd behavior if you're not careful.

[leandromoh]

I know structs are value types and stored on the stack, as well mutable structs are not the recommendation, but still can figure out why compiler makes a defensive copy by its own just when I mark the field as readonly 😟

You are reassigning the field, though.

not in my c#, but in the IL generated by the compiler! by my self, I cant make it, even if I want to since the field is marked as readonly
in my c# code, the core field is assigned exactly once (in the constructor).

You don't have a readonly struct

maybe happened a misunderstood here. i know the type is not a readonly struct, I meant that the field is a struct and also readonly. edited in the post to avoid new confusions.

[Clockwork-Muse]

I know structs are value types and stored on the stack

On the stack isn't important here. The important bit is that the actual value of the struct is saved into the field itself. This is why I said "but you are reassigning the field" - the act of mutation would modify the field.
Since you disallowed that (since you added readonly to the field, the only way for the compiler to enforce this with a mutable struct is to take the defensive copy.

[leandromoh]

oh now I got it !! thank you very much for the explanation @Clockwork-Muse.

[En3Tho]

Well, you have to remember that having a field marked read-only means that this piece of memory that this field occupies shouldn't be mutated by conventional means.

For class read-only fields this obviously means that a reference/pointer to the heap shouldn't be mutated/changed.

For struct read-only field this means that whatever fields you have on a struct, they become literally a part of your class body and they can't be mutated.

It works for a class fields because when you call a mutating method you know it will change the class body on the heap but not a read-only reference to it (you can see it as a read-only struct that contains a reference/pointer, actually).

For struct fields compiler has to make a defensive copy because you're calling a mutating method on read-only value itself