Ensure that INumberBase implements IUtf8SpanFormattable

[tannergooding]

Since IUtf8SpanFormattable is a net new interface in .NET 8, then we need to ensure that INumberBase implements it in the same release we can't hit a diamond problem in the future.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Since IUtf8SpanFormattable is a net new interface in .NET 8, then we need to ensure that INumberBase implements it in the same release we can't hit a diamond problem in the future.

Author:	tannergooding
Assignees:	tannergooding
Labels:	area-System.Numerics, new-api-needs-documentation
Milestone:	-

[GrabYourPitchforks]

Nit: No slice is needed here.

[tannergooding]

Its not "needed", but its nice to be consistent with the general pattern that is needed in most algorithms. It helps avoid copy/paste or refactoring errors.

It also helps limit the amount of work done if the utf8Buffer would've been "too small" and the rented buffer was much larger, for whatever reason (that is, it allows faster and more consistent failure).

[GrabYourPitchforks]

Nit: I would just use utf8Destination.Length directly for this. That is, just assume ASCII to simplify things. You're not going to be able to tell how many UTF-8 bytes the intermediate buffer will transcode to until after the intermediate buffer has already been populated, so...meh.

[tannergooding]

Same as above, its not strictly "needed" and in the 99% case won't even be different since it really only is length + 1 and check for overflow.

But, its nice to be consistent with the generally "correct" pattern and helps cover any edges that might creep in for user code. Our own APIs won't be hitting the DIM anyways.

[danmoseley]

nit, I don't think these comments add much

[tannergooding]

It’s a copy/paste of the same comment we have throughout similar code. I agree it probably doesn’t add much, but it’s consistent atm

[panxn]

This change causes C3611 error in my c++/cli project, any idea?

error C3611: 'System::Numerics::INumberBase::System::IUtf8SpanFormattable.TryFormat': a sealed function cannot have a pure-specifier

I can simply reproduce it with following sample:

    // in C# project
    public interface Interface
    {
        bool TryFormat();
    }
    public interface Interface2 : Interface
    {
        bool Interface.TryFormat()
        {
            return true;
        }
    }
    public class MyClass : Interface2
    {
    }

    // in C++/CLI project, error C3611
    auto p = gcnew CSharpDll::MyClass();

[tannergooding]

This change causes C3611 error in my c++/cli project, any idea?

Seems like a C++/CLI bug that is exposed when overriding an instance DIM in a derived interface.

This doesn't occur if the DIM is done on the interface that defines the API (that is, this wouldn't be an issue if the DIM was done on IUtf8SpanFormattable itself, but that would require it to implement ISpanFormattable).