Open wsy opened 2 months ago
Tagging subscribers to this area: @dotnet/area-system-runtime See info in area-owners.md if you want to be subscribed.
See also #76225. The operator interfaces have been moved to System.Numerics
namespace, and implemented on numeric types only.
Additionally, GUID is more opaque and doesn't support other arithmetic operations like TimeSpan
.
One of the key considerations is also that for things like equality
or comparison
, IEqualityOperators
and IComparisonOperators
are typically not what you want.
You instead typically want the much older and pre-existing IEquatable
and IComparable
interfaces.
operator ==
and Equals
have different contracts/implementation requirements. For example, Equals
has strict requirements that it follow the concept of .NET equality
that is usable alongside GetHashCode
and which allows it to work for collections
, hash sets
, and other considerations (such as guaranteeing identity equality, transitive equality, etc). While operator ==
has no such requirements and can basically do "anything" that is correct for the type.
This comes up in practice for things involving floating-point fields where float.NaN == float.NaN
returns false
but float.NaN.Equals(float.NaN)
returns true
.
That isn't to say that Guid
couldn't implement IEqualityOperators
or IComparisonOperators
, but more just pointing out that even if they did you probably don't want to be using them in most scenarios.
Background and motivation
Sometimes we want to abstract common CRUD operations to a base class and we would like to make them generic. These data classes/records will have a property named Id as primary key. When we use Guid as primary key, it won't fit in the generic constraint even though it has already overridden the '==' and '!=' operator.
API Proposal
API Usage
Alternative Designs
No response
Risks
I consider this API suggestion as "No Risks".