-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Breaking] Avoid boxing on equality and comparison #1280
Comments
I personally believe the likelihood would increase if this would be an opt-in behavior, e.g. a separate project-wide setting. Like a language-feature flag which is preview only, not becoming the default for vNext automatically. |
I think for this particular change an opt out is good. Nobody will be able to explore and opt into it. |
I would love to get the perf benefits here, would love to work with generic |
Just here to say that this:
Is something I'd put in L or XL size. There were several attempts to land this in the compiler before and one the reasons why is because it's complex and difficult to implement. There's also a long tail of legacy code that will now fail at runtime in subtle ways, which needs to be dealt with. |
I would say this suggestion (deferring to We would need a notice similar to https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/7.0/equals-nan .
It would be good to see a concrete example. Is there some existing plausible code which would depend, for correctness, on I think it's much more likely that there will be a long tail of subtle bugs that would be fixed by this change, rather than created by this change, since it is much more likely that programs would assume that |
Draft RFC here fsharp/fslang-design#747 |
Pretty much all code which uses floating point comparison, may implicitly rely on it. So it will be hugely runtime breaking. Another question, whether these applications relying on NaNs. |
General discussion for breaking changes in corelib: dotnet/fsharp#16231 |
Question: is dotnet/fsharp#526 |
It's a partial fix for the problem, a workaround really, at the cost of additional codegen. |
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 aBackCompat
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 fromIEquatable<T>
and relying onnan <> nan
without 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.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:
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.
The text was updated successfully, but these errors were encountered: