Update standard numeric format parsing to handle higher precision #22458
Labels
breaking-change
Indicates a .NET Core breaking change
🏁 Release: .NET 6
Issues and PRs for the .NET 6 release
doc-idea
Indicates issues that are suggestions for new topics [org][type][category]
Pri1
High priority, do before Pri2 and Pri3
Projects
Update the parsing/formatting logic to allow for precision more than 99 digits
Currently, the standard numeric format parsing logic is limited to precision <= 99. Some numeric types have more precision, but
ToString(string format)
does not expose it correctly. With dotnet/runtime#46874, we now support precision up toint.MaxValue
. Precision >int.MaxValue
will throw aFormatException
. Since the change occurs in the parsing logic, this will affect all numeric types.Version introduced
.NET 6 Preview 2
Old behavior
Did not support precision > 99. For ex:
32.ToString("C100")
will printC132
. This occurred because the parse routine interpreted precision more than 99 as a custom numeric format string. Consequently formats such asH100
would be interpreted as a custom format and print wrong values whileH99
would throw because it was (correctly) interpreted as an unsupported standard formatNew behavior
The new rule is: A format modifier with any number of digits is interpreted as a standard format + precision. If the value doesn't fit into an
int
, we throw.For ex:
32.ToString("C100")
will print$32.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Unsupported formats such as
32.ToString("H100")
will throw a FormatException.Reason for change
Fix unexpected behavior when using higher precision.
Recommended action
If you are using formats such as
G142
today, you are technically encountering a bug. If you want to maintain the previous behavior (i.e. where 42.ToString("G999") was intentionally meant to return G999), you can explicitly single quote the first character (i.e. 42.ToString("'G'999")). This will work on .NET Framework, .NET Core, and .NET 5+Format strings, like the following, would continue to be interpreted as "custom numeric format strings":
Category
Affected APIs
Issue metadata
The text was updated successfully, but these errors were encountered: