Never use mutable structs as in in argument - is it **Never**

[gmanvel]

Under the section Never use mutable structs as in in argument the reasoning is that in order to ensure readonly-ness of mutable structs passed using in modifier defensive copies had to be made.
This behavior doesn't seem to be consistent across different compiler versions.

If I use mutable struct, which is being passed with in modifier, with older versions of the compiler the defensive copy is indeed created. (sharplab.io)

However, same code with recent version of Roslyn, compiles to IL where defensive copy is not made. (sharplab.io)

If mutable struct uses non-auto-properties, then defensive copies are made regardless of compiler version. (sharplab.io)

Btw, I can see this behavior in .NET Core 2.1 app (C# 7.3) created in VS 2019.

Is there some kind of optimization in place when auto-properties are used ? Is this behavior documented anywhere ? If so can we refer to it ?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: ac8804c7-6acd-ab2a-4e14-0b99265969a5
• Version Independent ID: 183efcbd-a781-d303-f9cd-1c22da1676de
• Content: Write safe and efficient C# code
• Content Source: docs/csharp/write-safe-efficient-code.md
• Product: dotnet-csharp
• GitHub Login: @BillWagner
• Microsoft Alias: wiwagn

[BillWagner]

Ping @jcouv

Are there optimizations in place for the behavior described above?

I'm hesitant to update this article unless those optimizations are something we want to guarantee in future versions. Thoughts?

[jcouv]

Tagging @RikkiGibson

[RikkiGibson]

https://github.com/dotnet/csharplang/blob/1f8c618f4ba42e8962bd1acb5f18bf36c2c550a1/proposals/csharp-8.0/readonly-instance-members.md

Readonly can be applied to some auto-implemented properties, but it won't have a meaningful effect. The compiler will treat all auto-implemented getters as readonly whether or not the readonly keyword is present.

This only applies when the project is built with C# 8 or later. Perhaps we should also revise the spec to be clear about this.

[gmanvel]

@RikkiGibson thanks for reference. From what I understand it applies to projects built with C# 8 or later, I can see this behavior in the .NET Core 2.1 project built with C# 7.3.

Reproducible code in sharplab.io.

[svick]

@gmanvel As I understand it, the copy is avoided if the struct was compiled using C# 8.0.

E.g.:

// lib:
public struct S
{
    public int X { get; set; }
}

// app:
class Program
{
    static int M(in S s) => s.X;
}

If I compile lib with C# 8.0 and app with C# 7.3, the IL for M is:

    IL_0000: ldarg.0      // s
    IL_0001: call         instance int32 [lib]S::get_X()
    IL_0006: ret

If I compile lib with C# 7.3 and app with C# 8.0, the IL is:

    IL_0000: ldarg.0      // s
    IL_0001: ldobj        [lib]S
    IL_0006: stloc.0      // V_0
    IL_0007: ldloca.s     V_0
    IL_0009: call         instance int32 [lib]S::get_X()
    IL_000e: ret

Maybe that's the situation you're in? If not, can you provide repro code? (SharpLab master uses C# 8.0, so that doesn't count.)

[gmanvel]

@svick no, not the same situation.

To reproduce:
Visual Studio Professional 2019 (version 16.1.6)
Create a new .NET Core 2.1 console application, set language to 7.3 (Project Properties -> Build -> Advanced -> Language version: C# 7.3)

namespace CSharpTestsVs2019
{
    using System;
    class Program
    {
        static void Main(string[] args)
        {
            var s = new S(0);
            
            PrintS(in s);
        }

        private static void PrintS(in S s)
        {
            Console.WriteLine(s.X);
        }
    }

    public struct S
    {
        public S(double x)
        {
            this.X = x;
        }

        public double X { get; set; }
    }
}

Generated IL I see (for Release build):

.method private hidebysig static void
    Main(
      string[] args
    ) cil managed
  {
    .entrypoint
    .maxstack 2
    .locals init (
      [0] valuetype CSharpTestsVs2019.S s
    )

    // [8 13 - 8 30]
    IL_0000: ldloca.s     s
    IL_0002: ldc.r8       0.0
    IL_000b: call         instance void CSharpTestsVs2019.S::.ctor(float64)

    // [10 13 - 10 26]
    IL_0010: ldloca.s     s
    IL_0012: call         void CSharpTestsVs2019.Program::PrintS(valuetype CSharpTestsVs2019.S&)

    // [11 9 - 11 10]
    IL_0017: ret

  } // end of method Program::Main

  .method private hidebysig static void
    PrintS(
      [in] valuetype CSharpTestsVs2019.S& s
    ) cil managed
  {
    .param [1]
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.IsReadOnlyAttribute::.ctor()
      = (01 00 00 00 )
    .maxstack 8

    // [15 13 - 15 36]
    IL_0000: ldarg.0      // s
    IL_0001: call         instance float64 CSharpTestsVs2019.S::get_X()
    IL_0006: call         void [System.Console]System.Console::WriteLine(float64)

    // [16 9 - 16 10]
    IL_000b: ret

  } // end of method Program::PrintS

[svick]

@gmanvel Ok, I can reproduce that with Roslyn 3.1.0 (which is the version used by VS 16.1), but not in Roslyn 3.2.0 (which is used by VS 16.2).

As far as I can tell, this is a bug that was fixed by @RikkiGibson in dotnet/roslyn#35213. If you want to see the correct behavior, you should update your version of Visual Studio.

[gmanvel]

@svick thank you, updating VS now shows the correct behavior.
Closing the ticket.