在很长一段时间之后，我又回到了C#，并试图用C#10这本书来迎头赶上.
那里的作者提到，将属性的访问器从init更改为set或反之亦然是一个突破性的变化.我能理解为什么把它从set改为init会是一个突破性的变化，但我就是不明白为什么反过来改变它会是一个突破性的变化.
例如:
//Assembly 1
Test obj = new(){A = 20};
//Assembly 2
class Test
{
public int A {get; init;} = 10;
}
即使我将init属性访问器更改为set，程序集1中的此代码也不会受到影响.那么，为什么这是一个突破性的变化呢？
这是因为init个访问器被编译成一个带有modreq声明的setter.Int属性P的IL代码可能如下所示(请参见第SharpLab部分):
.method public hidebysig specialname
instance void modreq([System.Runtime]System.Runtime.CompilerServices.IsExternalInit) set_P (
int32 'value'
) cil managed
{
...
}
请注意 token modreq([System.Runtime]System.Runtime.CompilerServices.IsExternalInit).
普通的setter不会生成这个modreq.
在调用方，当且仅当该方法上存在modreq时，Call指令必须提供modreq声明作为要调用的事物的签名的一部分.因此，对init访问器的调用将如下所示:
callvirt instance void modreq([System.Runtime]System.Runtime.CompilerServices.IsExternalInit) SomeClass::set_P(int32)
而且不仅仅是
callvirt instance void SomeClass::set_P(int32)
如果更改为setter，则必须更改对init访问器的所有调用以删除modreq，否则它将无法正确解析该方法.因此，这是一个突破性的变化.
至于为什么使用modreq而不是常规属性来标记特性，请参见规范草案中的this section.总而言之，这是二进制兼容性和"编译器不知道init个访问器会做什么"之间的权衡.最后，他们决定牺牲二进制兼容性，以便不了解init doesn't的编译器允许代码设置该属性.