[FS-1138] Avoid boxing on equality and comparison

[Happypig375]

Click “Files changed” → “⋯” → “View file” for the rendered RFC.

[cartermp]

Perhaps I'm mistaken, but I thought it was rejected on the grounds that it always looked for IEquatable<'T>.Equals first instead of obj.Equals, which has the potential to break any class implementation that doesn't follow the (non-required) .NET guidance for implementing IEquatable<'T>.Equals. That's a far larger breaking change than simply breaking nan comparison.

[Happypig375]

The only systematical deviation is NaN comparison which may apply to System.Half, and other floating point representations that have a NaN value.

Do you have more examples of IEquatable<`T> deviating from obj.Equals?

[cartermp]

I've not seen anyone on the compiler team state that this only affects nan equality. The PR linked says nothing about that, it explicitly states that anyone can make obj.Equals and IEquatable<T>.Equals have different behavior, and this would be a runtime-breaking change for them. Over the course of 13+ years of F# being a supported enterprise product in VS, there is undoubtedly code in the wild that works perfectly today and will be broken silently when there is an updated F# compiler delivered by their tools.

Not saying this means the feature stops, but I've simply not seen "we need preserve the weird nan behavior" as the actual reason for not accepting work like this in the past.

[Happypig375]

Ok, so hypothetically someone somewhere could be broken. Any examples?

[abelbraaksma]

This chat got a bit stale, but @Happypig375 I think you are asking about where obj.Equals can result in different response than IEquatable.Equals.

The simplest example is probably that the default implementation for obj.Equals is often reference equality, which would return false for two different instances of the same object (let's say two persons that are have field name = "Happy Pig"). Using IEquatable.Equals(a, b), this would return true instead.

Another case might be certain time and date instances, perhaps from NodaTime, but I haven't checked, where two instances may be bitwise unequal, but considered equal after resolving, say, the timezone.

However, an argument can be made that if you implement IEquality.Equals that you would want it to behave similar to object.Equals.

[abelbraaksma]

In fact, reading more on it in several blog posts and about Microsoft accepting the oddity of nan = nan => false, nan <> nan => true, but forcing the incompatible change for nan.Equals(nan) => true and (nan :> IEquatable<float>).Equals(nan) => true strengthens me in the believe that making this change would be a good thing ™️. :)

[abelbraaksma]

@Happypig375 I am wondering if the new PR dotnet/fsharp#16857, which was just merged, removes the requirement for this RFC and/or replaces it.

I'll make a note in that particular PR as well. Perhaps we can update this RFC to address the changes over there done by @psfinaki?

[psfinaki]

So this suggestion, starting with its title in the RFC doc, mixes a few things together: NaNs and unnecessary boxing, and also this unnecessary boxing is currently happening in many places. Generally, the situation is quite nicely overviewed here now.

The NaN problem is still there and should be addressed. I guess we can either rewrite this RFC or close this one + a new one. Just saying that the more focused the suggestions are, the easier they are to reason about. I know I sound like Captain Obvious but IMO that's exactly the reason why all these problems have been take so long here.

[abelbraaksma]

No, I totally agree. And by focusing the NaN problem to mimic the C# track, we would have a more tailored and succinct discussion.

Ideally, I would just compare all blittable types as binary blobs and have the fastest speed up possible for equality, but unfortunately, that's not going to work for many reasons (some of which are shown in that white paper on equality optimizations).