Add primitive type Span-based Parse/TryParse/TryFormat methods

[stephentoub]

Separated out of https://github.com/dotnet/corefx/issues/21281 for tracking purposes.

• Implement parsing in System.Private.CoreLib in coreclr
• Implement parsing in System.Private.CoreLib in corert (unless primitive types are "shared" by then)
• Expose parsing from System.Runtime contract in corefx
• Add parsing tests to System.Runtime tests in corefx
• Implement formatting in System.Private.CoreLib in coreclr
• Implement formatting in System.Private.CoreLib in corert (unless primitive types are "shared" by then)
• Expose formatting from System.Runtime contract in corefx
• Add formatting tests to System.Runtime tests in corefx

namespace System
{
    public struct Int16
    {
        public short Parse(ReadOnlySpan<char> s, NumberStyles style = NumberStyles.Integer, IFormatProvider provider = null);
        public bool TryParse(ReadOnlySpan<char> s, out short result, NumberStyles style = NumberStyles.Integer, IFormatProvider provider = null);

        public bool TryFormat(Span<char> destination, out int charsWritten, string format = null, IFormatProvider provider = null);
        …
    }

    … // similar Parse/TryParse/TryFormat methods for each of:
    // Int32
    // Int64
    // UInt16
    // UInt32
    // UInt64
    // Decimal
    // Double
    // Single
    // Boolean (but no NumberStyle/NumberFormatInfo args)
}

[WinCPP]

@stephentoub may I work on this?

[stephentoub]

@WinCPP, sure, thanks. Note that this one will likely require lots of perf testing to verify existing parse/formatting functionality isn't regressed, as the right way to implement it is likely to make lots of small changes around the existing implementations to switch from using arrays to using spans so that both the array-based and span-based entrypoints can share the same mostly-existing code paths.

[WinCPP]

@stephentoub yup I understand.

[WinCPP]

@stephentoub I think I need to let go off this issue that I grabbed. Being remote, I think I am handicapped in knowing what is being done / what is to be done. And this one appears to be quite a big one to do by myself. Sorry for the haste... Although I can work collaboratively...

[stephentoub]

Ok, thanks.

[stephentoub]

The implementation of the parsing side of this is complete. The formatting side still needs to be done, and would benefit from corert's managed formatting implementation being ported to coreclr, where the formatting is currently done in native code in the runtime.

[stephentoub]

Formatting work depends on https://github.com/dotnet/coreclr/issues/13544

[mazong1123]

Since we have new implementation of formatting in native coreclr (dotnet/coreclr#12894 and an in-progress one dotnet/coreclr#14646), is it better to port these native implementations to managed code other than port from corert?

[stephentoub]

Separated decimal, double, and single TryFormat methods into their own issues. Everything else is complete as of dotnet/corefx#25307.

[YairHalberstadt]

Is there any reason char.TryParse wasn't updated? Or is it simply considered to niche to be worthwhile?

[stephentoub]

Is there any reason char.TryParse wasn't updated? Or is it simply considered to niche to be worthwhile?

Just because it doesn't really add value in that there's no actual parsing, just accessing a single character in the string. Instead of:

if (char.TryParse(str, out char c))
{
    Use(c);
}

you just do:

if (!string.IsNullOrEmpty(str))
{
    Use(str[0]);
}