{U}Int128 support for Utf8Formatter/Parser

[hrrrrustic]

Close #73842

The implementation is almost copy-paste from {U}Int64 as same as other integer types doing for previous size types. I can try to reduce some duplication, but not sure if it's possible without any performance losses

Holding draft to see CI tests, fix missed type casts and possible typos

Blocked by #73842 (comment)

[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-memory
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Close #73842

The implementation is almost copy-paste from {U}Int64 as same as other types doing for previous size types. I can try to reduce some duplication, but not sure if it's possible without any performance losses

Holding draft to see CI tests

Author:	hrrrrustic
Assignees:	-
Labels:	area-System.Memory, new-api-needs-documentation, community-contribution
Milestone:	-

[stephentoub]

@tannergooding, do we still want new methods on Utf8Formatter for UInt128 / Int128? With UTF8 support now baked into the types, Utf8Formatter is largely obsolete.

[tannergooding]

do we still want new methods on Utf8Formatter for UInt128 / Int128? With UTF8 support now baked into the types, Utf8Formatter is largely obsolete.

I think its probably worth a timeboxed discussion in API review. UTF8Parser still serves a purpose in that it treats the first invalid character as "end of string" rather than "failure.

Having Int128 support in the parser, but not a mirror in the formatter then seems a bit odd. Not being able to more generally express the parsing behavior is also a bit odd/limiting.

I think the ideal scenario, in my mind, would be to not expose this support for UTF8Formatter or UTF8Parser and instead expose a new NumberStyles.AllowInvalidCharacterForEndOfString (but a better name). This would allow both UTF8Formatter and UTF8Parser to both be "effectively obsolete" and to also bring the support up to the UTF16 space so we have parity.

If we did decide to provide it on UTF8Parser, then I think it would be best to also provide it on UTF8Formatter for consistency.

[stephentoub]

UTF8Parser still serves a purpose

Yup. I was referring specifically to Utf8Formatter. The only argument I see for adding to it at this point is when we add something to Utf8Parser and then want some kind of consistency between them even though we would discourage anyone from using the Utf8Formatter APIs. While I'm all for consistency, adding APIs we don't actually want folks to use isn't desirable.

I think the ideal scenario, in my mind, would be to not expose this support for UTF8Formatter or UTF8Parser and instead expose a new NumberStyles.AllowInvalidCharacterForEndOfString (but a better name)

I'm fine with that, too. Then both Utf8Formatter and Utf8Parser are entirely obsolete, whether we choose to mark them as such or not.

[tannergooding]

I've opened #87171 covering the proposed new functionality. Depending on API review we may want to either keep the PR as is -or- to pull what's been implemented so far into the general parsing logic.

[ghost]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.