I propose we solve dotnet/fsharp#526 (accepting the breaking change at dotnet/fsharp#9404 due to use of IEquatable<T> and IComparable<T>). We will include a BackCompat module to enable past behaviour. These current behaviours typically have no known instance of usage and the breaking change is only theoretical for code that already is designed poorly in the first place, like .Equals behaving differently from IEquatable<T> and relying on nan <> nan without using System.Double.IsNaN (IEquatable<double> makes nan = nan).
The existing way of approaching this problem in F# is taking the cost of boxing every equality and comparison for structs. Retaining the same behaviour has made F# perform worse than C#. We are keeping a reason for C# people not to move over simply because we retain a behaviour no one wants.
dotnet/fsharp#526 (comment)
Anyway, it has lost me as an fsharp developer, which is a shame as I really love writing code in fsharp, but with advancements in csharp over the years, it's, for the type of code I write, a lesser worse option
Pros and Cons
The advantages of making this adjustment to F# are
- Great performance
- One less reason for C# people not to move over
- One less reason for people to abandon F#
The disadvantage of making this adjustment to F# is this is a breaking change after all. But as mentioned, it's a hypothetical breaking change only. There is no known instance of people depending on IEquatable<T> behaving differently from .Equals as this is poor design.
Extra information
Estimated cost (XS, S, M, L, XL, XXL): S
Related suggestions:
We should do this together with another wart in FSharp.Core that has gone unnoticed, in the same update: #472
Affidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply:
For Readers
If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.
I propose we solve dotnet/fsharp#526 (accepting the breaking change at dotnet/fsharp#9404 due to use of
IEquatable<T>andIComparable<T>). We will include aBackCompatmodule to enable past behaviour. These current behaviours typically have no known instance of usage and the breaking change is only theoretical for code that already is designed poorly in the first place, like.Equalsbehaving differently fromIEquatable<T>and relying onnan <> nanwithout usingSystem.Double.IsNaN(IEquatable<double>makesnan = nan).The existing way of approaching this problem in F# is taking the cost of boxing every equality and comparison for structs. Retaining the same behaviour has made F# perform worse than C#. We are keeping a reason for C# people not to move over simply because we retain a behaviour no one wants.
dotnet/fsharp#526 (comment)
Pros and Cons
The advantages of making this adjustment to F# are
The disadvantage of making this adjustment to F# is this is a breaking change after all. But as mentioned, it's a hypothetical breaking change only. There is no known instance of people depending on
IEquatable<T>behaving differently from.Equalsas this is poor design.Extra information
Estimated cost (XS, S, M, L, XL, XXL): S
Related suggestions:
We should do this together with another wart in FSharp.Core that has gone unnoticed, in the same update: #472
Affidavit (please submit!)
Please tick this by placing a cross in the box:
This is arguing against a previous decision not to accept this breaking change.
Please tick all that apply:
For Readers
If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.