❔ ✅ Using generics that implement IEqualityOperators results in ambiguous call to the == operator

SharpLab
C#/VB/F# compiler playground.
12 Replies
phaseshift
phaseshift2y ago
show code and show exact error please
JansthcirlU
JansthcirlU2y ago
hey sorry for the slow reply, I can't reproduce the error on my machine somehow, it happened on my work pc, I'll update my post later
Accord
Accord2y ago
Looks like nothing has happened here. I will mark this as stale and this post will be archived until there is new activity.
JansthcirlU
JansthcirlU2y ago
Also tagging @tannergooding cause it's a numerics thing
tannergooding
tannergooding2y ago
IComparisonOperators implies IEqualityOperators so you've defined both IEqualityOperators<TRow, TRow, bool> and IEqualityOperators<TRow, TRow, TRow> therefore overloading by return type which is not normally supported thus C# cannot determine which of the two you want
JansthcirlU
JansthcirlU2y ago
Oh I see, I should've checked So just comparison operators is enough then
tannergooding
tannergooding2y ago
it depends. How are you expecting IComparisonOperators to work given the return type is TRow and not bool?
JansthcirlU
JansthcirlU2y ago
Hmm, good question, I guess the element that precedes the other should be returned, similar to how IComparable returns its ints
tannergooding
tannergooding2y ago
There are some cases where that can make sense, such as Vector128<T> GreaterThan(Vector128<T>, Vector128<T>) which return a per element mask but, you should typically have that as a different API so that the normal usage of x > y works in typical user expressions/etc
JansthcirlU
JansthcirlU2y ago
I see, I guess if I'm not working with numbers explicitly I could stick to just equality stuff Thanks! !close
Accord
Accord2y ago
Closed! Was this issue resolved? If so, run /close - otherwise I will mark this as stale and this post will be archived until there is new activity.