- changed status to open
Vector<T>.Equals misses overload with TEqualityComparison<T>/IEqualityComparer<T>
Issue #410
open
Hi!
We found out that Vector<T>.Equals misses overload with TEqualityComparison<T>/IEqualityComparer<T>. That would be very useful for Vectors of records.
Because we understand that looking up the equality class operator in runtime is not efficient for basic type like Vector.
And there is already a method Contains with comparison/comparer as paramer.
Kind regards,
Zigmund.
Comments (4)
-
repo owner -
repo owner - changed milestone to 2.1
-
assigned issue to
-
reporter By “looking up the equality class operator in runtime” I meant to find out the class operator “Equal”.. or GetHashCode (as you mention).
-
repo owner Yes, but it does not do that.
- Log in to comment
I will consider extending.
There is one statement in your report that I think is a wrong conclusion. "looking up the equality class operator in runtime" - how does that relate to a custom equality comparer?
Currently, it is the case (as it is in the RTL) - and it is something I would like to change but there is no clear "this is the correct way" solution - that the default equality comparer for a record type simply does a binary compare of the record memory. And that is often wrong. There can be paddings due to record field alignment that might contain garbage data that was not zeroed for various reasons or it might contain reference types that need a deep equality check rather than just their pointer.
One idea I had was providing a generic custom equality comparer for records that first try to look for an equals operator and a GetHashCode function via RTTI - that only needs to be done one time and after that, they can be directly called. If these methods are not there it would do a field-by-field comparison similar to how System._CopyRecord works.
Also, I think there is some room for improvement for the current Vector<T>.Equals implementation for trivially equatable types such as Integer - it can simply mem compare instead of looping.