ComparisonIdentity.Structural.Compare returns different values for Option wrapped types

[manofstick]

My regression tests for #513 have shown up the following inconsistency in existing f#:

printfn "%d" <| (ComparisonIdentity.Structural.Compare (SByte.MinValue, SByte.MaxValue))
printfn "%d" <| (ComparisonIdentity.Structural.Compare (Some SByte.MinValue, Some SByte.MaxValue))

Output

-1
-255

It is due to FSharpOption's type generic call to:

LanguagePrimitives.HashCompare.GenericComparisonWithComparerIntrinsic<T>(genericComparer, x, y);

Now I doubt if anyway is using comparers in any other way than < 0 or > 0, but they may be? #513 is a potentially breaking change because it returns -1 for the Option case - i.e. matching the primitive operation (although the affects of this breaking case, to Option comparison operations being sensitive to particular return values - is almost vanishingly small I would say..)

(The good news is that if in my regression limits Compare to (sign of Compare) then I'm getting no regression errors. I'll put my regression test up soon)

[manofstick]

Playing around a bit this seems to be the case only for primitives that are < 32 bits. Even more smaller probability that this affects real code...

[manofstick]

I have just fixed #513 to regression test properly (I.e. it now acts in same way as existing configuration), but this is still an oddity of the existing configuration along with the #527 & #556 (although this is less severe than those)

[latkin]

I don't think this is worth worrying about. It's well-documented that comparison results should only be considered for 0, < 0 or > 0.

[manofstick]

I agree. (For regression purposes trying to just be 100% with what is currently there so I don't have to look at any individual cases, but I would like to achieve ComparerIdentity.Structural as equal to System.Collections.Generic.Comparers.Default where they shouldn't differ - even if it is still "valid": values)

[dsyme]

Yes, this is not a bug, will close it as by design