The property of `Struct Record` should add [<IsReadOnly>] for the read operation

[RealmPlume]

I just read the article https://docs.microsoft.com/en-us/dotnet/csharp/write-safe-efficient-code,
and checked. I see that when I use C # to write the following code:

    struct Bar
    {
        public int Item1 { get; set;}
        public int Item2 { get; set;}
    }

Actually Item1 is compiled as:

public int Item1
{
	[IsReadOnly]
	[CompilerGenerated]
	get
	{
		return <Item1>k__BackingField;
	}
	[CompilerGenerated]
	set
	{
		<Item1>k__BackingField = value;
	}
}

See, It adds a [IsReadOnly] attribute in front. So, I think it can be recognized and optimized by the C # compiler when it is passed as a parameter.

But if I write F # code like this:

[<Struct>]
type Bar = {
    Value: int
    mutable Text: string
}

compiled as:

[CompilationMapping(SourceConstructFlags.Field, 1)]
public string Text
{
	get
	{
		return Text@;
	}
	set
	{
		Text@ = value;
	}
}
[CompilationMapping(SourceConstructFlags.Field, 0)]
public int Value
{
	get
	{
		return Value@;
	}
	set
	{
		Value@ = value;
	}
}

Neither Value nor Text adds the [IsReadOnly] attribute above get.
Now if I pass the record to a C # function as readonly mode, even if I only do a read operation, the ldobj instruction will be generated.

But C # struct will not.

[abelbraaksma]

So, I think it can be recognized and optimized by the C # compiler when it is passed as a parameter.

@greatim, Jon Skeet wrote about readonly fields having the opposite effect on performance (see ,https://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields/), mainly because the C# compiler creates extra copies. I'm not sure it applies here, but if so, it may not have a positive impact at all (though there's certainly a semantic impact and potentially a backwards incompatibility if this gets changed).

[RealmPlume]

mainly because the C# compiler creates extra copies. I'm not sure it applies here, but if so, it may not have a positive impact at all (though there's certainly a semantic impact and potentially a backwards incompatibility if this gets changed).

No, I tested it, it only affects compile time, not runtime.
F#:

[<Struct>]
type Bar = 
    val mutable private item1: int
    val mutable private item2: int
    new (a, b) = {
        item1 = a
        item2 = b
    }    
    member __.Item1 with [<IsReadOnly>] get() = __.item1
    member __.Item2 with [<IsReadOnly>] get() = __.item2 

C#:

static int  Foo(in Bar bar) {
        return bar.Item1 + bar.Item2;
}

C# generates IL:

.method private hidebysig static 
	int32 Foo (
		[in] valuetype [Library1]Library/Bar& bar
	) cil managed 
{
	.param [1]
		.custom instance void [mscorlib]System.Runtime.CompilerServices.IsReadOnlyAttribute::.ctor() = (
			01 00 00 00
		)
	// Method begins at RVA 0x2076
	// Code size 14 (0xe)
	.maxstack 8

	// return bar.Item1 + bar.Item2;
	IL_0000: ldarg.0
	IL_0001: call instance int32 [Library1]Library/Bar::get_Item1()
	IL_0006: ldarg.0
	IL_0007: call instance int32 [Library1]Library/Bar::get_Item2()
	IL_000c: add
	// (no C# code)
	IL_000d: ret
} // end of method Program::Foo

when I turn off [<IsReadOnly>] before get(), C# generates IL:

.method private hidebysig static 
	int32 Foo (
		[in] valuetype [Library1]Library/Bar& bar
	) cil managed 
{
	.param [1]
		.custom instance void [mscorlib]System.Runtime.CompilerServices.IsReadOnlyAttribute::.ctor() = (
			01 00 00 00
		)
	// Method begins at RVA 0x2078
	// Code size 30 (0x1e)
	.maxstack 2
	.locals init (
		[0] valuetype [Library1]Library/Bar
	)

	// return bar.Item1 + bar.Item2;
	IL_0000: ldarg.0
	IL_0001: ldobj [Library1]Library/Bar
	IL_0006: stloc.0
	// (no C# code)
	IL_0007: ldloca.s 0
	IL_0009: call instance int32 [Library1]Library/Bar::get_Item1()
	IL_000e: ldarg.0
	IL_000f: ldobj [Library1]Library/Bar
	IL_0014: stloc.0
	IL_0015: ldloca.s 0
	IL_0017: call instance int32 [Library1]Library/Bar::get_Item2()
	IL_001c: add
	IL_001d: ret
} // end of method Program::Foo

quite impressive

[RealmPlume]

Maybe it could be a additional attribute for Record. Otherwise, we cannot add [] annotation by ourselves.

[abelbraaksma]

when I turn off [], C# generates IL

And

we cannot add [] annotation by ourselves.

@greatim, What did you mean to write inside []? Was it [<IsReadOnly>]? On github, stuff that looks like an XML tag gets erased, but you can escape it with a backslash, or put it inside back quotes.

But good to know the referred behavior mentioned by Jon Skeet is not applicable here (or has since been optimized).

[RealmPlume]

@greatim, What did you mean to write inside []? Was it [<IsReadOnly>]?
yes, I didn't preview . Escapes no work. I use full-width now.

[abelbraaksma]

Escapes no work. I use full-width now.

@greatim This is what I meant with escapes (you only need one):

 Attribute [\<test>]

Renders as: Attribute [<test>]. Though back quotes is generally easier and more readable, and work with any code, so you don't need to remember what characters to escape:

Attribute `[<test>]`

Renders as: Attribute [<test>].

[cartermp]

So this isn't quite the same scenario, but this struct:

[<Struct>]
type Bar(x: int, y: int) =
    member _.Item1 = x
    member _.Item2 = y

Should probably emit IsReadOnly on the get methods.