Description
There are inconsistencies with how NumberStyles.AllowLeadingWhite and AllowTrailingWhite behave. Incorrect handling of the former means that if a user has their system set to use this standard available format in Windows, numbers can never be parsed back from that string representation:
This seems rather problematic, i.e. if an application is displaying numeric values in a textbox using the user's preferred format, which is typically what is done, then it will fail to convert that value back to its numeric type.
Reproduction Steps
var style = NumberStyles.AllowLeadingWhite |
NumberStyles.AllowTrailingWhite |
NumberStyles.AllowLeadingSign |
NumberStyles.AllowTrailingSign;
int.Parse("123 -", style) // Ok with AllowTrailingWhite
int.Parse("- 123", style) // Always throws, even with AllowLeadingWhite This next inconsistency is likely related, and although it is less problematic (since the standard formats don't put spaces here), it is still an odd inconsistency:
var style = NumberStyles.AllowLeadingWhite |
NumberStyles.AllowTrailingWhite |
NumberStyles.AllowParenthesis;
int.Parse("(123 )", style) // Ok with AllowTrailingWhite
int.Parse("( 123)", style) // Always throws, even with AllowLeadingWhite Expected behavior
The first issue with the sign should be fixed so that AllowLeadingWhite allows whitespace to lead the number after the sign.
The second issue I'm a bit agnostic about, but I thought I should mention it. It's probably too late to make it stricter and not allow spaces on either side, so either loosen the behavior so whitespace can lead the number after the opening parenthesis (which may just happen naturally as part of the fix to the first issue), or leave it as-is.
Actual behavior
See above.
Regression?
No response
Known Workarounds
No response
Configuration
.NET 8
Other information
No response
Description
There are inconsistencies with how
NumberStyles.AllowLeadingWhiteandAllowTrailingWhitebehave. Incorrect handling of the former means that if a user has their system set to use this standard available format in Windows, numbers can never be parsed back from that string representation:This seems rather problematic, i.e. if an application is displaying numeric values in a textbox using the user's preferred format, which is typically what is done, then it will fail to convert that value back to its numeric type.
Reproduction Steps
This next inconsistency is likely related, and although it is less problematic (since the standard formats don't put spaces here), it is still an odd inconsistency:
Expected behavior
The first issue with the sign should be fixed so that
AllowLeadingWhiteallows whitespace to lead the number after the sign.The second issue I'm a bit agnostic about, but I thought I should mention it. It's probably too late to make it stricter and not allow spaces on either side, so either loosen the behavior so whitespace can lead the number after the opening parenthesis (which may just happen naturally as part of the fix to the first issue), or leave it as-is.
Actual behavior
See above.
Regression?
No response
Known Workarounds
No response
Configuration
.NET 8
Other information
No response