blocks|key|89572|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|89573|这对于像int，double这样的内置原语意味着什么？|blockquote|89574|89575|89576|Nothing、int和double以及所有其他内置的“原语”都是不可变的。您不能改变double、int或DateTime。例如，System.Drawing.Point就是一个典型的框架类型，它不是一个好的候选者。|offset|length|style|CODE|89577|老实说，文档可以更清楚一些；在这种情况下，readonly是一个令人困惑的术语，它应该简单地说明类型应该是不可变的。|89578|没有规则可以知道任何给定的类型是否是不可变的；只有仔细检查API才能给出一个概念，或者，如果您幸运的话，文档可能会说明它是否是不可变的。|89579|entityMap^0|0|0|0|0|8|3|C|6|17|6|1E|3|1I|8|1U|K|0|0|0^^$0|@$1|2|3|-4|4|5|6|R|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|S|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|T|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|V|7|@$H|W|I|X|J|K]|$H|Y|I|Z|J|K]|$H|10|I|11|J|K]|$H|12|I|13|J|K]|$H|14|I|15|J|K]|$H|16|I|17|J|K]]|8|@]|9|$]]|$1|L|3|M|4|5|6|18|7|@]|8|@]|9|$]]|$1|N|3|O|4|5|6|19|7|@]|8|@]|9|$]]|$1|P|3|-4|4|5|6|1A|7|@]|8|@]|9|$]]]|Q|$]]

<blockquote>
 What does this mean for built-in primitives such as int, double?
</blockquote>

Nothing, <code>int</code> and <code>double</code> and all other built-in "primitives" are immutable. You can't mutate a <code>double</code>, an <code>int</code> or a <code>DateTime</code>. A typical framework type that would not be a good candidate is <code>System.Drawing.Point</code> for instance.

To be honest, the documentation could be a little bit clearer; readonly is a confusing term in this context, it should simply say the type should be immutable.

There is no rule to know if any given type is immutable or not; only a close inspection of the API can give you an idea or, if you are lucky, the documentation might state if it is or not.

blocks|key|89618|text|在当前的编译器中，似乎确实为'primitive‘值类型和其他非只读结构创建了防御性副本。具体地说，它们的生成方式类似于readonly字段:当访问可能会改变内容的属性或方法时。这些副本在每个调用点对一个潜在的变异成员显示为，所以如果您调用n个这样的成员，您将最终生成n个防御性副本。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|89619|看看this+suite+of+examples吧。您可以查看IL和JIT程序集。|89620|89621|在参数中通过传递原始类型而不进行防御性复制是否安全？|blockquote|89622|89623|89624|如果不是，你可能不会：|89625|//+Original:
int+In(in+int+_)+{
++++_.ToString();
++++_.GetHashCode();
++++return+_+>=+0+?+_+%2B+42+:+_+-+42;
}

//+Decompiled:
int+In([In]+[IsReadOnly]+ref+int+_)+{
++++int+num+=+_;
++++num.ToString();++++//+invoke+on+copy
++++num+=+_;
++++num.GetHashCode();+//+invoke+on+second+copy
++++if+(_+<+0)
++++++++return+_+-+42;+//+use+original+in+arithmetic
++++return+_+%2B+42;
}|code-block|syntax|javascript|89626|89627|是其他常用的框架结构，如DateTime、TimeSpan、Guid等。被编译器认为是只读的？|89628|89629|89630|不，对于这些类型的in参数上的潜在变异成员，仍将在调用点创建防御性副本。然而，有趣的是，并不是所有的方法和属性都被认为是“潜在的变异”。我注意到，如果我调用默认方法实现(例如，ToString或GetHashCode)，则不会发出防御性副本。|89631|struct+WithDefault+{}
struct+WithOverride+{+public+override+string+ToString()+=>+"RO";+}

//+Original:
void+In(in+WithDefault+d,+in+WithOverride+o)+{
++++d.ToString();
++++o.ToString();
}

//+Decompiled:
private+void+In([In]+[IsReadOnly]+ref+WithDefault+d,
++++++++++++++++[In]+[IsReadOnly]+ref+WithOverride+o)+{
++++d.ToString();++++++++++++//+invoke+on+original
++++WithOverride+withOverride+=+o;
++++withOverride.ToString();+//+invoke+on+copy
}|89632|89633|如果平台不同，我们如何找出在给定情况下哪些类型是安全的？|89634|89635|89636|好吧，所有的类型都是“安全的”--副本确保了这一点。我假设你问的是哪种类型可以避免防御性拷贝。如果不存在这样的引用，则不需要制作副本。此外，是否复制的决定可能取决于您是否调用一个已知是安全的或“纯”的成员，而不是一个可能会改变a值类型内容的成员。|89637|如果我不得不猜测，这是一个预先存在的行为的结果，编译器正在利用一些最初为readonly字段开发的“只读”引用的概念。正如您在下面看到的(或in+SharpLab)，行为是相似的。注意，在调用WithDefault.ToString时，IL如何使用ldflda+(按地址加载字段)将调用目标推送到堆栈上，但在调用WithOverride.ToString时，使用ldfld、stloc、ldloca序列将副本推送到堆栈上|89638|struct+WithDefault+{}
struct+WithOverride+{+public+override+string+ToString()+=>+"RO";+}

static+readonly+WithDefault+D;
static+readonly+WithOverride+O;

//+Original:
static+void+Test()+{
++++D.ToString();
++++O.ToString();
}

//+IL+Disassembly:
.method+private+hidebysig+static+void+Test+()+cil+managed+{
++++.maxstack+1
++++.locals+init+([0]+valuetype+Overrides/WithOverride)

++++//+[WithDefault]+Invoke+on+original+by+address:
++++IL_0000:+ldsflda+valuetype+Overrides/WithDefault+Overrides::D
++++IL_0005:+constrained.+Overrides/WithDefault
++++IL_000b:+callvirt+instance+string+[mscorlib]System.Object::ToString()
++++IL_0010:+pop

++++//+[WithOverride]+Copy+original+to+local,+invoke+on+copy+by+address:
++++IL_0011:+ldsfld+valuetype+Overrides/WithOverride+Overrides::O
++++IL_0016:+stloc.0
++++IL_0017:+ldloca.s+0
++++IL_0019:+constrained.+Overrides/WithOverride
++++IL_001f:+callvirt+instance+string+[mscorlib]System.Object::ToString()
++++IL_0024:+pop
++++IL_0025:+ret
}|89639|也就是说，既然只读引用可能会变得更加常见，那么可以在没有防御性副本的情况下调用的方法的“白名单”在未来可能会增长。就目前而言，这似乎有点武断。|89640|entityMap|0|LINK|mutability|MUTABLE|url|https://sharplab.io/#v2:D4AQDABAygFghgJwA4Bk4CMB0AlArgOwBcBLAWwFMBuAWACg6QAmCABQTOJIDdyBnCAN50IIiMSIQAkvgAU4sRID6ASkERFmACoB7KIXb4A5jOWV1mAOLlCACTi8YAYW0ATcibMgA7OogA%2BAF4ISAB%2BXwBqCAAWZgAuXwBaaMYzAF9hUXFCCGxyADMZBHyFbJU1DR09A2NTcytbeydXd1qK3X1xGs8fRQhImLSMkSyIADU4ABs5JVUBc0qOow866zsHZzdltqrO5e8I5MHadPpaJggAWVxCDAnyKtwAY0J%2BIVpRCF59J%2BzsAHU1CAAMwQbQ8BDsNwQEAARkgC2qJggAT8EAARP80UchtColJZPJ/upZvN2ojWpZVo0Ni0zNtFl0ICcPiA8bkCkU8jkAWU5vTyXTKQ11s0tloybtaszRKyxpMZETeaSdksKfU1k1NhSEZKjicGMxcnAXAB5fATACeD2erxxRWN2nNFs%2B32eORNgJBYPIEOIUNh8IlquRqIxJqxTLoONl0mm7uJ5XFKsZGnV1NF2qDjOlIll7MKxWwHqV/N1K2FmtpyoZyxzuLlUyLCb5SZraqpIq1gp1qr1UbOzCs%2BB9xEetveoi%2BCB%2B3M9oPBkPI0LhEB7NRD6MxRw%2B9pcjstLunbqbc2B859i%2BXgeTSJRm/D2Inubxmj4hCRbw%2BH1jMVMOO/sjDgA7tyJh/k%2BX6xsB7pgTQEH6hBADaABSnBDiOjwyIQFpIOQ2gFFkyjKAANBAqGEOh7CYdhuH4QqfxEaR5GUaOWE4XhBRFkRAC60Z4tIAA8mh%2BHGmjNtWArlhqNJimutZ8ficaKiSpa9lJ6ZdhJZZ1jGBL4PGJatpJqYdpWslZvJxx0EAA|1|https://sharplab.io/#v2:C4LglgNgPgAgTAAgEoFMCGATA8gOwgTwDEwUIMAVFAZ2CoQG8BYAKATYRoCcBXAY2AQB1MMAAWAERQAzNNwgD6AXxbsOwHvyEjRWAG4pOnMBhQMEMAMwIA9vsPHTMAIwAGBOWsBldWBwBzAAoASgQAXgA%2BBAAiJCwogG4EZVZ2FXZnADYETnQMazx8LTFJGTkBcXi0tkzs3PyCIp07IxMELErmKvMnLJgAFndqYGCGLtVxADoPbyN/YI7VVSwprx85oIX2ZMUgA=^0|1O|8|34|U|0|0|15|2|M|0|0|0|0|Q|0|0|0|0|B|0|0|0|0|1B|0|0|0|0|3D|9|2|2G|8|2P|B|0|0|0|0|S|0|0|0|0|3F|0|0|5U|10|8|2O|K|3G|6|4C|L|51|5|57|5|5D|6|1Y|B|1|0|0|0|1Z|0^^$0|@$1|2|3|4|5|6|7|1R|8|@$9|1S|A|1T|B|C]|$9|1U|A|1V|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|1W|8|@$9|1X|A|1Y|B|D]]|E|@$9|1Z|A|20|1|21]]|F|$]]|$1|I|3|-4|5|6|7|22|8|@]|E|@]|F|$]]|$1|J|3|K|5|L|7|23|8|@$9|24|A|25|B|D]]|E|@]|F|$]]|$1|M|3|-4|5|6|7|26|8|@]|E|@]|F|$]]|$1|N|3|-4|5|6|7|27|8|@]|E|@]|F|$]]|$1|O|3|P|5|6|7|28|8|@$9|29|A|2A|B|D]]|E|@]|F|$]]|$1|Q|3|R|5|S|7|2B|8|@]|E|@]|F|$T|U]]|$1|V|3|-4|5|6|7|2C|8|@]|E|@]|F|$]]|$1|W|3|X|5|L|7|2D|8|@$9|2E|A|2F|B|D]]|E|@]|F|$]]|$1|Y|3|-4|5|6|7|2G|8|@]|E|@]|F|$]]|$1|Z|3|-4|5|6|7|2H|8|@]|E|@]|F|$]]|$1|10|3|11|5|6|7|2I|8|@$9|2J|A|2K|B|D]|$9|2L|A|2M|B|C]|$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]]|E|@]|F|$]]|$1|12|3|13|5|S|7|2R|8|@]|E|@]|F|$T|U]]|$1|14|3|-4|5|6|7|2S|8|@]|E|@]|F|$]]|$1|15|3|16|5|L|7|2T|8|@$9|2U|A|2V|B|D]]|E|@]|F|$]]|$1|17|3|-4|5|6|7|2W|8|@]|E|@]|F|$]]|$1|18|3|-4|5|6|7|2X|8|@]|E|@]|F|$]]|$1|19|3|1A|5|6|7|2Y|8|@$9|2Z|A|30|B|D]]|E|@]|F|$]]|$1|1B|3|1C|5|6|7|31|8|@$9|32|A|33|B|D]|$9|34|A|35|B|C]|$9|36|A|37|B|C]|$9|38|A|39|B|C]|$9|3A|A|3B|B|C]|$9|3C|A|3D|B|C]|$9|3E|A|3F|B|C]|$9|3G|A|3H|B|C]]|E|@$9|3I|A|3J|1|3K]]|F|$]]|$1|1D|3|1E|5|S|7|3L|8|@]|E|@]|F|$T|U]]|$1|1F|3|1G|5|6|7|3M|8|@$9|3N|A|3O|B|D]]|E|@]|F|$]]|$1|1H|3|-4|5|6|7|3P|8|@]|E|@]|F|$]]]|1I|$1J|$5|1K|1L|1M|F|$1N|1O]]|1P|$5|1K|1L|1M|F|$1N|1Q]]]]

With the current compiler, defensive copies do indeed appear to be made for both 'primitive' value types and other non-readonly structs. Specifically, they are generated similarly to how they are for <code>readonly</code> fields: when accessing a property or method that could potentially mutate the contents. The copies appear at each call site to a potentially mutating member, so if you invoke n such members, you'll end up making n defensive copies. As with <code>readonly</code> fields, you can avoid multiple copies by manually copying the original to a local.

Take a look at <a href="https://sharplab.io/#v2:D4AQDABAygFghgJwA4Bk4CMB0AlArgOwBcBLAWwFMBuAWACg6QAmCABQTOJIDdyBnCAN50IIiMSIQAkvgAU4sRID6ASkERFmACoB7KIXb4A5jOWV1mAOLlCACTi8YAYW0ATcibMgA7OogA+AF4ISAB+XwBqCAAWZgAuXwBaaMYzAF9hUXFCCGxyADMZBHyFbJU1DR09A2NTcytbeydXd1qK3X1xGs8fRQhImLSMkSyIADU4ABs5JVUBc0qOow866zsHZzdltqrO5e8I5MHadPpaJggAWVxCDAnyKtwAY0J+IVpRCF59J+zsAHU1CAAMwQbQ8BDsNwQEAARkgC2qJggAT8EAARP80UchtColJZPJ/upZvN2ojWpZVo0Ni0zNtFl0ICcPiA8bkCkU8jkAWU5vTyXTKQ11s0tloybtaszRKyxpMZETeaSdksKfU1k1NhSEZKjicGMxcnAXAB5fATACeD2erxxRWN2nNFs+32eORNgJBYPIEOIUNh8IlquRqIxJqxTLoONl0mm7uJ5XFKsZGnV1NF2qDjOlIll7MKxWwHqV/N1K2FmtpyoZyxzuLlUyLCb5SZraqpIq1gp1qr1UbOzCs+B9xEetveoi+CB+3M9oPBkPI0LhEB7NRD6MxRw+9pcjstLunbqbc2B859i+XgeTSJRm/D2Inubxmj4hCRbw+H1jMVMOO/sjDgA7tyJh/k+X6xsB7pgTQEH6hBADaABSnBDiOjwyIQFpIOQ2gFFkyjKAANBAqGEOh7CYdhuH4QqfxEaR5GUaOWE4XhBRFkRAC60Z4tIAA8mh+HGmjNtWArlhqNJimutZ8ficaKiSpa9lJ6ZdhJZZ1jGBL4PGJatpJqYdpWslZvJxx0EAA" rel="nofollow noreferrer">this suite of examples</a>. You can view both the IL and the JIT assembly.

<blockquote>
 Is it safe to pass primitive types via in arguments and not have defensive copies made?
</blockquote>

It depends on whether you access a method or property on the <code>in</code> parameter. If you do, you may see defensive copies. If not, you probably won't:

<pre><code>// Original:
int In(in int _) {
 _.ToString();
 _.GetHashCode();
 return _ &gt;= 0 ? _ + 42 : _ - 42;
}

// Decompiled:
int In([In] [IsReadOnly] ref int _) {
 int num = _;
 num.ToString(); // invoke on copy
 num = _;
 num.GetHashCode(); // invoke on second copy
 if (_ &lt; 0)
 return _ - 42; // use original in arithmetic
 return _ + 42;
}
</code></pre>

<blockquote>
 Are other commonly used framework structs such as DateTime, TimeSpan, Guid, ... considered readonly by [the compiler]?
</blockquote>

No, defensive copies will still be made at call sites for potentially mutating members on <code>in</code> parameters of these types. What's interesting, though, is that not all methods and properties are considered 'potentially mutating'. I noticed that if I called a default method implementation (e.g., <code>ToString</code> or <code>GetHashCode</code>), no defensive copies were emitted. However, as soon as I overrode those methods, the compiler created copies:

<pre><code>struct WithDefault {}
struct WithOverride { public override string ToString() =&gt; "RO"; }

// Original:
void In(in WithDefault d, in WithOverride o) {
 d.ToString();
 o.ToString();
}

// Decompiled:
private void In([In] [IsReadOnly] ref WithDefault d,
 [In] [IsReadOnly] ref WithOverride o) {
 d.ToString(); // invoke on original
 WithOverride withOverride = o;
 withOverride.ToString(); // invoke on copy
}
</code></pre>

<blockquote>
 If this varies by platform, how can we find out which types are safe in a given situation?
</blockquote>

Well, all types are 'safe'--the copies ensure that. I assume you're asking which types will avoid a defensive copy. As we've seen above, it's more complicated than "what's the type of the parameter"? There's no single copy: the copies are emitted at certain references to <code>in</code> parameters, e.g., where the reference is an invocation target. If no such references are present, no copies need to be made. Moreover, the decision whether to copy can depend on whether you invoke a member that is known to be safe or 'pure' vs. a member which could potentially mutate the a value type's contents.

For now, certain default methods seem to be treated as pure, and the compiler avoids making copies in those cases. If I had to guess, this is a result of preexisting behavior, and the compiler is utilizing some notion of 'read only' references that was originally developed for <code>readonly</code> fields. As you can see below (or <a href="https://sharplab.io/#v2:C4LglgNgPgAgTAAgEoFMCGATA8gOwgTwDEwUIMAVFAZ2CoQG8BYAKATYRoCcBXAY2AQB1MMAAWAERQAzNNwgD6AXxbsOwHvyEjRWAG4pOnMBhQMEMAMwIA9vsPHTMAIwAGBOWsBldWBwBzAAoASgQAXgA+BAAiJCwogG4EZVZ2FXZnADYETnQMazx8LTFJGTkBcXi0tkzs3PyCIp07IxMELErmKvMnLJgAFndqYGCGLtVxADoPbyN/YI7VVSwprx85oIX2ZMUgA=" rel="nofollow noreferrer">in SharpLab</a>), the behavior is similar. Note how the IL uses <code>ldflda</code> (load field by address) to push the invocation target onto the stack when calling <code>WithDefault.ToString</code>, but uses a <code>ldfld</code>, <code>stloc</code>, <code>ldloca</code> sequence to push a copy onto the stack when invoking <code>WithOverride.ToString</code>:

<pre><code>struct WithDefault {}
struct WithOverride { public override string ToString() =&gt; "RO"; }

static readonly WithDefault D;
static readonly WithOverride O;

// Original:
static void Test() {
 D.ToString();
 O.ToString();
}

// IL Disassembly:
.method private hidebysig static void Test () cil managed {
 .maxstack 1
 .locals init ([0] valuetype Overrides/WithOverride)

 // [WithDefault] Invoke on original by address:
 IL_0000: ldsflda valuetype Overrides/WithDefault Overrides::D
 IL_0005: constrained. Overrides/WithDefault
 IL_000b: callvirt instance string [mscorlib]System.Object::ToString()
 IL_0010: pop

 // [WithOverride] Copy original to local, invoke on copy by address:
 IL_0011: ldsfld valuetype Overrides/WithOverride Overrides::O
 IL_0016: stloc.0
 IL_0017: ldloca.s 0
 IL_0019: constrained. Overrides/WithOverride
 IL_001f: callvirt instance string [mscorlib]System.Object::ToString()
 IL_0024: pop
 IL_0025: ret
}
</code></pre>

That said, now that read only references will presumably become more common, the 'white list' of methods that can be invoked without defensive copies may grow in the future. For now, it seems somewhat arbitrary.

blocks|key|2826298|text|快速测试表明，目前，是的，为内置的原始类型和结构创建了一个防御性副本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2826299|使用VS+2017+(.NET+4.5.2，C#+7.2，release+build)编译以下代码：|2826300|using+System;

class+MyClass
{
++++public+readonly+struct+Immutable+{+public+readonly+int+I;+public+void+SomeMethod()+{+}+}
++++public+struct+Mutable+{+public+int+I;+public+void+SomeMethod()+{+}+}

++++public+void+Test(Immutable+immutable,+Mutable+mutable,+int+i,+DateTime+dateTime)
++++{
++++++++InImmutable(immutable);
++++++++InMutable(mutable);
++++++++InInt32(i);
++++++++InDateTime(dateTime);
++++}

++++void+InImmutable(in+Immutable+x)+{+x.SomeMethod();+}
++++void+InMutable(in+Mutable+x)+{+x.SomeMethod();+}
++++void+InInt32(in+int+x)+{+x.ToString();+}
++++void+InDateTime(in+DateTime+x)+{+x.ToString();+}

++++public+static+void+Main(string[]+args)+{+}
}|code-block|syntax|javascript|2826301|使用ILSpy反编译时会产生以下结果：|2826302|...
private+void+InImmutable([System.Runtime.CompilerServices.IsReadOnly]+[In]+ref+MyClass.Immutable+x)
{
++++x.SomeMethod();
}

private+void+InMutable([System.Runtime.CompilerServices.IsReadOnly]+[In]+ref+MyClass.Mutable+x)
{
++++MyClass.Mutable+mutable+=+x;
++++mutable.SomeMethod();
}

private+void+InInt32([System.Runtime.CompilerServices.IsReadOnly]+[In]+ref+int+x)
{
++++int+num+=+x;
++++num.ToString();
}

private+void+InDateTime([System.Runtime.CompilerServices.IsReadOnly]+[In]+ref+DateTime+x)
{
++++DateTime+dateTime+=+x;
++++dateTime.ToString();
}
...|2826303|(或者，如果您喜欢使用IL:)|2826304|IL_0000:+ldarg.1
IL_0001:+ldobj+[mscorlib]System.DateTime
IL_0006:+stloc.0
IL_0007:+ldloca.s+0
IL_0009:+call+instance+string+[mscorlib]System.DateTime::ToString()
IL_000e:+pop
IL_000f:+ret|2826305|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

A quick test shows that, currently, yes, a defensive copy is created for built-in primitive types and structs.

Compiling the following code with VS 2017 (.NET 4.5.2, C# 7.2, release build):

<pre><code>using System;

class MyClass
{
 public readonly struct Immutable { public readonly int I; public void SomeMethod() { } }
 public struct Mutable { public int I; public void SomeMethod() { } }

 public void Test(Immutable immutable, Mutable mutable, int i, DateTime dateTime)
 {
 InImmutable(immutable);
 InMutable(mutable);
 InInt32(i);
 InDateTime(dateTime);
 }

 void InImmutable(in Immutable x) { x.SomeMethod(); }
 void InMutable(in Mutable x) { x.SomeMethod(); }
 void InInt32(in int x) { x.ToString(); }
 void InDateTime(in DateTime x) { x.ToString(); }

 public static void Main(string[] args) { }
}
</code></pre>

yields the following result when decompiled with ILSpy:

<pre><code>...
private void InImmutable([System.Runtime.CompilerServices.IsReadOnly] [In] ref MyClass.Immutable x)
{
 x.SomeMethod();
}

private void InMutable([System.Runtime.CompilerServices.IsReadOnly] [In] ref MyClass.Mutable x)
{
 MyClass.Mutable mutable = x;
 mutable.SomeMethod();
}

private void InInt32([System.Runtime.CompilerServices.IsReadOnly] [In] ref int x)
{
 int num = x;
 num.ToString();
}

private void InDateTime([System.Runtime.CompilerServices.IsReadOnly] [In] ref DateTime x)
{
 DateTime dateTime = x;
 dateTime.ToString();
}
...
</code></pre>

(or, if you prefer IL:)

<pre><code>IL_0000: ldarg.1
IL_0001: ldobj [mscorlib]System.DateTime
IL_0006: stloc.0
IL_0007: ldloca.s 0
IL_0009: call instance string [mscorlib]System.DateTime::ToString()
IL_000e: pop
IL_000f: ret
</code></pre>

blocks|key|2826312|text|从jit的角度来看，in更改了参数的调用约定，使其始终按引用传递。因此，对于原语类型(复制成本很低)和通常按值传递的类型，如果使用in，调用方和被调用方都会有少量额外开销。然而，没有防御性的拷贝。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2826313|例如在|2826314|using+System;
using+System.Runtime.CompilerServices;

class+X
{
++++[MethodImpl(MethodImplOptions.NoInlining)]
++++static+int+F0(in+int+x)+{+return+x+%2B+1;+}

++++[MethodImpl(MethodImplOptions.NoInlining)]
++++static+int+F1(int+x)+{+return+x+%2B+1;+}

++++public+static+void+Main()
++++{
++++++++int+x+=+33;
++++++++F0(x);
++++++++F0(x);
++++++++F1(x);
++++++++F1(x);
++++}
}|code-block|syntax|javascript|2826315|Main的代码是|2826316|+++C744242021000000+++++mov++++++dword+ptr+[rsp%2B20H],+33
+++488D4C2420+++++++++++lea++++++rcx,+bword+ptr+[rsp%2B20H]
+++E8DBFBFFFF+++++++++++call+++++X:F0(byref):int
+++488D4C2420+++++++++++lea++++++rcx,+bword+ptr+[rsp%2B20H]
+++E8D1FBFFFF+++++++++++call+++++X:F0(byref):int
+++8B4C2420+++++++++++++mov++++++ecx,+dword+ptr+[rsp%2B20H]
+++E8D0FBFFFF+++++++++++call+++++X:F1(int):int
+++8B4C2420+++++++++++++mov++++++ecx,+dword+ptr+[rsp%2B20H]
+++E8C7FBFFFF+++++++++++call+++++X:F1(int):int|2826317|注意:由于in+x的原因，无法注册。|2826318|F0+&+F1的代码显示，前者现在必须从byref中读取值：|2826319|;;+F0
+++8B01+++++++++++++++++mov++++++eax,+dword+ptr+[rcx]
+++FFC0+++++++++++++++++inc++++++eax
+++C3+++++++++++++++++++ret

;;+F1
+++8D4101+++++++++++++++lea++++++eax,+[rcx%2B1]
+++C3+++++++++++++++++++ret|2826320|如果jit内联，这个额外的开销通常可以取消，但并不总是如此。|2826321|entityMap^0|A|2|1T|2|0|0|0|0|4|0|0|5|2|0|0|7|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|15|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|16|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|O|3|P|5|J|7|1A|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|1B|8|@$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|U|3|V|5|J|7|1H|8|@]|D|@]|E|$K|L]]|$1|W|3|X|5|6|7|1I|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|1J|8|@]|D|@]|E|$]]]|Z|$]]

From the jit's standpoint <code>in</code> alters the calling convention for a parameter so that it is always passed by-reference. So for primitive types (which are cheap to copy) and normally passed by-value, there a small extra cost on both the caller's side and the callee's side if you use <code>in</code>. No defensive copies are made, however.

Eg in 

<pre><code>using System;
using System.Runtime.CompilerServices;

class X
{
 [MethodImpl(MethodImplOptions.NoInlining)]
 static int F0(in int x) { return x + 1; }

 [MethodImpl(MethodImplOptions.NoInlining)]
 static int F1(int x) { return x + 1; }

 public static void Main()
 {
 int x = 33;
 F0(x);
 F0(x);
 F1(x);
 F1(x);
 }
}
</code></pre>

The code for <code>Main</code> is

<pre><code> C744242021000000 mov dword ptr [rsp+20H], 33
 488D4C2420 lea rcx, bword ptr [rsp+20H]
 E8DBFBFFFF call X:F0(byref):int
 488D4C2420 lea rcx, bword ptr [rsp+20H]
 E8D1FBFFFF call X:F0(byref):int
 8B4C2420 mov ecx, dword ptr [rsp+20H]
 E8D0FBFFFF call X:F1(int):int
 8B4C2420 mov ecx, dword ptr [rsp+20H]
 E8C7FBFFFF call X:F1(int):int
</code></pre>

Note because of the <code>in</code> x can't be enregistered.

And the code for <code>F0 &amp; F1</code> shows the former must now read the value from the byref:

<pre><code>;; F0
 8B01 mov eax, dword ptr [rcx]
 FFC0 inc eax
 C3 ret

;; F1
 8D4101 lea eax, [rcx+1]
 C3 ret
</code></pre>

This extra cost can usually be undone if the jit inlines, though not always.

C# 7.2 introduced the <code>in</code> modifier for passing arguments by reference with the guarantee that the recipient will not modify the parameter.

This <a href="https://blogs.msdn.microsoft.com/seteplia/2018/03/07/the-in-modifier-and-the-readonly-structs-in-c/" rel="noreferrer">article</a> says:

<blockquote>
 You should never use a non-readonly struct as the in parameters because it may negatively affect performance and could lead to an obscure behavior if the struct is mutable
</blockquote>

What does this mean for built-in primitives such as <code>int</code>, <code>double</code>?

I would like to use <code>in</code> to express intent in code, but not at the cost of performance losses to defensive copies.

Questions

<ul>
<li>Is it safe to pass primitive types via <code>in</code> arguments and not have defensive copies made?</li>
<li>Are other commonly used framework structs such as <code>DateTime</code>, <code>TimeSpan</code>, <code>Guid</code>, ... considered <code>readonly</code> by the JIT?

<ul>
<li>If this varies by platform, how can we find out which types are safe in a given situation?</li>
</ul></li>
</ul>

Using C# 7.2 in modifier for parameters with primitive types

编译器

C# 7.2引入了in修饰符，用于通过引用传递参数，并保证接收者不会修改参数。此表示：切勿将非只读结构用作in参数，因为这可能会对性能产生负面影响，并且如果该结构是可变的，还可能导致模糊的行为这对于int、double等内置原语意味着什么我想使用in在代码中表达意图，但不会以防御性副本的性能损失为代价。问题通过in参数...

问在具有基元类型的参数的修饰符中使用C# 7.2
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在具有基元类型的参数的修饰符中使用C# 7.2EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在具有基元类型的参数的修饰符中使用C# 7.2
EN