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

Pphaseshift2/11/2023
show code and show exact error please
JJansthcirlU2/11/2023
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
AAccord2/12/2023
Looks like nothing has happened here. I will mark this as stale and this post will be archived until there is new activity.
JJansthcirlU2/13/2023
Also tagging @tannergooding cause it's a numerics thing
Ttannergooding2/13/2023
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
Ttannergooding2/13/2023
thus C# cannot determine which of the two you want
JJansthcirlU2/13/2023
Oh I see, I should've checked
JJansthcirlU2/13/2023
So just comparison operators is enough then
Ttannergooding2/13/2023
it depends.
How are you expecting IComparisonOperators to work given the return type is TRow and not bool?
JJansthcirlU2/13/2023
Hmm, good question, I guess the element that precedes the other should be returned, similar to how IComparable returns its ints
Ttannergooding2/13/2023
There are some cases where that can make sense, such as Vector128<T> GreaterThan(Vector128<T>, Vector128<T>)
which return a per element mask
Ttannergooding2/13/2023
but, you should typically have that as a different API so that the normal usage of x > y works in typical user expressions/etc
JJansthcirlU2/13/2023
I see, I guess if I'm not working with numbers explicitly I could stick to just equality stuff
JJansthcirlU2/13/2023
Thanks!
JJansthcirlU2/13/2023
!close
AAccord2/13/2023
Closed!
AAccord2/14/2023
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.