[release/8.0-preview7] Workaround a C++/CLI bug involving DIMs - #89264
Conversation
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
|
Tagging subscribers to this area: @dotnet/area-system-numerics Issue DetailsBackport of #89253 to release/8.0-preview7 /cc @jeffhandley @tannergooding Customer ImpactTestingRiskIMPORTANT: If this backport is for a servicing release, please verify that:
|
Backport of #89253 to release/8.0-preview7
/cc @jeffhandley @tannergooding
Customer Impact
The dotnet/wpf repo is currently blocked trying to build with Preview 7, and backporting this workaround to Preview 7 will unblock the builds. Using C++/CLI cannot currently compile applications referencing .NET 8 Preview 7, and this workaround unblocks the builds.
Testing
Ensured C++/CLI compilation succeeds with this change in place
Risk
There is currently a C++/CLI bug involving implementing an instance DIM on a derived interface. This causes C++/CLI to error when using any type that implements such an interface, which in the case of
System.Numerics.INumberBase<TSelf>includes all the primitive types (such asInt32orSingle).There were a few possible changes that would temporarily resolve this issue...
IUtf8SpanFormattableto have a DIM where it always throwsPlatformNotSupportedException, but this could lead to unexpected behavior for consumers of the APIIUtf8SpanFormattableto have a DIM where it always returnsfalse, but this risks users naively doing the wrong thing and trying to grow the buffer and call the API repeatedly as that's how the otherTryFormatAPIs workIUtf8SpanFormattableto inherit fromISpanFormattableand have a DIM where it defers to that implementationOf these options, 1 or 4 are the least risky.
4 would end up changing the shipping API surface and would not require a reversion later. It has the downside in that it requires everyone implementing
IUtf8SpanFormattableto also supportISpanFormattable(that isUTF-16). This puts more restriction on the API surface overall. That being said, it is the better option if we believe that the C++/CLI fix will not make the .NET 8 release as avoids us introducing a diamond problem in the future as the DIM is provided in the same release that the relevant interface and API are defined.1 (this change) will require us to revert this PR once the C++/CLI fix goes in. Not reverting this workaround will result in
INumberBase<TSelf>not being able to implementIUtf8SpanFormattablewithout risking the introduction of a diamond problem, since other types/interfaces could implementIUtf8SpanFormattablewith a DIM before the .NET 9 release.