Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Interpretation of ByRefLikeAttribute in .NET Core 2.1 is a breaking change and a standard violation #18280
As a matter of facts, it is possible in .NET Core 2.0 to use a ref struct as an argument of a generic parameter if you're generating MSIL, but this same MSIL code no longer runs in .NET Core 2.1. We used this compilation pattern in PostSharp and did all the testing in .NET Core 2.0, just to see it's breaking in .NET Core 2.1.
I understand why you guys have taken this approach as this is a pragmatic way, but I think it is my role as a third-party tool developer to respectfully complain.
Giving a runtime meaning to a custom attribute (ByRefLikeAttribute) is non-standard-compliant (ECMA-335), so the least I would expect is that you document an extension or violation of the standard. An orthodox approach would have been to define a new TypeAttribute and to cope with the problem that the compiler will need a specific version of the runtime.
The concrete impact for this change and as far as PostSharp is concerned is minimal because support for C# 7.2 in PostSharp wasn't made RTW yet.
However, as a policy, breaking standards and relying on "tricks" (like ObsoleteAttribute) to minimize their impact is unhealthy and warrants this complain.
It seems there's a need for a well-thought solution to this problem. Like .NET Standard is the API-level answer to this issue, should it be some CLR Standard? Maybe the compiler could emit a list of non-standard-compliant extensions, marked as MUST UNDERSTAND or OPTIONAL, that all members of the MSIL pipeline (therefore including the compiler, PostSharp and the CLR) would respect.
Thank you for reporting this issue. I am sorry for the pain that this is causing to PostSharp.
We have been historically trying hard to make new C# language features work on existing runtimes. It often results in shards like what is described here because of it is not possible to go back in time and fix the existing runtimes to work great with the new features. Another recent example of such shard is the recently introduced
We are re-evaluting the strategy going forward. I agree that we need to document this better.
The proper runtime support by byref-like types and features that depend on it (e.g. fast span) won't ever show up in .NET Framework update for this reason.
No damage/pain for us this time but it would be alarming if this became a trend.
Could we start a discussion about the 'MUST UNDERSTAND or OPTIONAL extension' idea? It does not seem a big implementation work but it could provide a long-term solution to this issue. Of course this itself is a breaking change ;).
As someone who is active in projects that often deal with low-level, runtime & reflection bits (e.g. Moq, Castle DynamicProxy), I would welcome such a discussion.
I'm going off a bit on a tangent here, but the terms that @gfraiteur is using ("must understand" and "optional") happen to coincide with the custom modifiers ("cmods") mechanism that the ECMA 335 has long known. I'm worried about one thing here: Reflection's support for cmods is somewhat spotty, and partially broken. (I can provide evidence if required.) Unlike C++/CLI, C# didn't use cmods for a long time, but it has now started using them for things such as the
I'd be really happy if the C# language design team and the (Core)CLR developers made sure that Reflection is not left behind, or it'll become increasingly difficult or even impossible to work with.