-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RuntimeHandles should implement IEquatable #62944
Comments
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsBackground and motivation
The runtime handles already implement strongly typed API Proposalnamespace System
{
public struct RuntimeTypeHandle : IEquatable<RuntimeTypeHandle>
{
// bool Equals(RuntimeTypeHandle) already exists
}
public struct RuntimeMethodHandle : IEquatable<RuntimeMethodHandle>
{
// bool Equals(RuntimeMehtodHandle) already exists
}
public struct RuntimeFieldHandle : IEquatable<RuntimeFieldHandle>
{
// bool Equals(RuntimeFieldHandle) already exists
}
} API UsageNo boxing. Alternative DesignsNo response RisksNo response
|
To make sure ApiCompat tooling runs at least in some legs, compile libs against NativeAOT corelib if we're building CLR, but not building the JIT flavor of the runtime. The baselining is necessary because the reflection stack of NativeAOT doesn't live in CoreLib. The CannotRemoveBaseTypeOrInteface baselining will go away once we fix dotnet#62944. It's one of the "overall goodness" things we can take out of NativeAOT and put it into all runtimes.
To make sure ApiCompat tooling for NativeAOT's CoreLib runs at least in some legs, compile libs against NativeAOT CoreLib if we're building CLR, but not building the JIT flavor of the runtime. The baselining is necessary because the reflection stack of NativeAOT doesn't live in CoreLib. The CannotRemoveBaseTypeOrInteface baselining will go away once #62944 gets fixed. It's one of the "overall goodness" things we can take out of NativeAOT and put it into all runtimes.
namespace System
{
public struct RuntimeTypeHandle : IEquatable<RuntimeTypeHandle>
{
// bool Equals(RuntimeTypeHandle) already exists
}
public struct RuntimeMethodHandle : IEquatable<RuntimeMethodHandle>
{
// bool Equals(RuntimeMethodHandle) already exists
}
public struct RuntimeFieldHandle : IEquatable<RuntimeFieldHandle>
{
// bool Equals(RuntimeFieldHandle) already exists
}
} |
https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1066 ? |
Yes, we need to fix or suppress all of our occurrences and then turn it on: |
Fixed in #63358. IEquatable on all the other structs that have Equals should be a different issue, if we want such issue. Looks like one of those issues that are so big that we'll never get to them. |
Background and motivation
RuntimeTypeHandle
is often used as a key in a dictionary. See hits on github: https://grep.app/search?q=dictionary%3Cruntimetypehandle. The search results include high profile libraries such a CsWinRt.The runtime handles already implement strongly typed
Equals(XXXHandle other)
methods, but without the interfaces, dictionaries are going to use theEquals(object other)
implementations instead, needlessly boxing the argument, unless a custom comparer is provided (it isn't in the above search results...).API Proposal
API Usage
No boxing.
Alternative Designs
No response
Risks
No response
The text was updated successfully, but these errors were encountered: