Consider hiding legacy overloads for Math.DivRem

[SingleAccretion]

Background and Motivation

#42156 introduced some new overloads for Math.DivRem which follow more modern API design practices (and have way better naming). I think it would make sense to hide the existing ones to avoid potential confusion and save on some Intellisense real estate. The new overloads are functionally the same.

Proposed API

namespace System
{
    public static class Math
    {
+       [EditorBrowsable(EditorBrowsableState.Never)]
        public static int DivRem(int a, int b, out int result);
+       [EditorBrowsable(EditorBrowsableState.Never)]
        public static long DivRem(long a, long b, out long result);
    }
}

Risks

The primary risk would be confusion among people who could be surprised to see the existing overloads disappear. I think it is low though, as the new signatures are quite self-explanatory. Note: this change only impacts new code, so it can be expected that developers working on it would familiarize themselves with the new pattern, especially as it is the only one available for unsigned and native integers.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @tannergooding, @pgovind, @jeffhandley
See info in area-owners.md if you want to be subscribed.

Issue Details

Description:	Background and Motivation #42156 introduced some new overloads for Math.DivRem which follow more modern API design practices (and have way better naming). I think it would make sense to hide the existing ones to avoid potential confusion and save on some Intellisense real estate. The new overloads are functionally the same. Proposed API namespace System { public static class Math { + [EditorBrowsable(EditorBrowsableState.Never)] public static int DivRem(int a, int b, out int result); + [EditorBrowsable(EditorBrowsableState.Never)] public static long DivRem(long a, long b, out long result); } } Risks The primary risk would be confusion among people who could be surprised to see the existing overloads disappear. I think it is quite low though, as the new signatures are quite self-explanatory. Note: this change only impacts new code, so it can expected that developers working on it would familiarize themselves with the new pattern, especially as it is the only one available for unsigned and native integers.
Author:	SingleAccretion
Assignees:	-
Labels:	api-suggestion, area-System.Numerics, untriaged
Milestone:	-

[tannergooding]

I've marked this api-ready-for-review so that the design review team can decide if this is appropriate or not.

[terrajobst]

Video

This could confuse people multi-targeting for .NET Standard because neither side is now a superset in IntelliSense. The value of hiding also seems low, especially because developers will typically explore alternative overloads and the tuple overloads will show first.