Make `Numerics` class internal

[stevenaw]

Most of NUnit's numeric-related work (comparisons, differences, equality) is exposed via constraints or the classic assertion model, but the work itself is done by a helper class: Numerics.

This helper class has public visibility, which means API changes to it require extra caution to ensure we don't break anyone. It might be helpful to look at if we can make this an internal class. This would be a breaking change, but I suspect it shouldn't be very disruptive. I haven't seen any usages of it in public repos based on a glance on https://grep.app

[stevenaw]

Usages

Numerics.Difference

https://grep.app/search?q=Numerics.Difference

No usages outside of NUnit

Numerics.Compare

https://grep.app/search?q=Numerics.Compare

Majority of references are to copies of either nunit.framework.xml or NUnitLite.XML which has been distributed from the NuGet package and committed to repos. xamarin/xamarin-android has a C# reference, but to a copy of the NUnit source within the repo rather than to NUnit itself.

Numerics.AreEqual

https://grep.app/search?q=Numerics.AreEqual

Similar to Numerics.Compare, references are mostly to the xml files distributed from the nuget package. xamarin/xamarin-android and shoudly each contain references to Numerics.AreEqual but each references a local class within the repo rather than to NUnit directly.

Numerics.IsFixedPointNumeric

https://grep.app/search?q=Numerics.IsFixedPointNumeric

Only references are to either nunit.framework.xml or NUnitLite.XML

Numerics.IsFloatingPointNumeric

https://grep.app/search?q=Numerics.IsFloatingPointNumeric

Only references are to either nunit.framework.xml or NUnitLite.XML

Numerics.IsNumericType

https://grep.app/search?q=Numerics.IsNumericType

Only references are to either nunit.framework.xml or NUnitLite.XML, or within local copies within xamarin/xamarin-android and shoudly

[stevenaw]

@CharliePoole This has already been triaged, but do you mind if I ask your thoughts here given a semi-recent comment by you in another issue of mine relating to that a large portion of Nunit usage is likely hidden in corporate or otherwise private codebases?

[CharliePoole]

If the class were in our Internal namespace, I wouldn't hesitate for a second. My opinion has always been that the namespace is sufficient warning to anybody who might make use of it.

However, it's in the Constraints namespace, which I believe was for two reasons:

1. Way back in time, we didn't use the Internal namespace.
2. It was envisioned that someone would want to add new numerics by extending the class. In fact, however, I don't think that's really possible the way the constraint library has developed.

If I were deciding, I'd break compatibility for V4.0 by changing this, but follow the usual compatibility rules for 3.x. However, it's really a policy decision for the framework team.

[stevenaw]

Thanks @CharliePoole always appreciate your historical insights.

It was envisioned that someone would want to add new numerics by extending the class. In fact, however, I don't think that's really possible the way the constraint library has developed.

FWIW, this may not apply in this case as Numerics is static.

[x789]

I am happy to make the proposed change. @stevenaw, can you assign this to me?

[stevenaw]

Thanks for your interest @x789 and thanks for assigning this @mikkelbu 😁

@x789 a change like this would probably require two PRs (one into v3.13-dev to mark it as obsolete, and one into the main/master branch to make it internal)

[x789]

Both PRs are merged. Since this issue is still open, I wonder if there is any work left?