Harmonise `AvaloniaObject` equality comparison

AvaloniaObject.Equals and GetHashCode are overridden, but only to seal the methods and prevent derived types from overriding them. This is fine at runtime, but causes static code analysis tools to think that the type has special equality logic. In my project this leads to annoying compile warnings every time we use == to compare two controls. Our CI rejects any commit containing these warnings.

To Reproduce Steps to reproduce the behavior:

1. Compare two AvaloniaObject variables with ==
2. Run Resharper on your solution with PossibleUnintendedReferenceComparison enabled
3. Resharper will warn about the comparison

Expected behavior There are two options:

1. AvaloniaObject should stop overriding Equals and GetHashCode. An analyzer diagnostic can be emitted to warn anyone who tries to override those methods in a derived type.
2. AvaloniaObject should also provide operator == and operator !=, so that code analysis tools think that everything is customised and stops warning about it.

I think option 1 is preferable, because sealing the methods does not stop users from defining their own static equality operators.

Desktop

• OS: N/A
• Version 11 RC 1.1

[maxkatz6]

Note that WPF’s DependencyObject doesn’t override == operator. I suppose there is a perf penalty for doing so.

Is it really a problem with modern runtime? I am pretty sure if will be inlined to the same code nowadays.

[kekekeks]

https://youtrack.jetbrains.com/issue/RSRP-492562/Possible-unintended-reference-comparison-for-AvaloniaObject