Negative numeric parsing inconsistencies / can't parse standard Windows format option

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

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

Not sure whether number parsing should be labeled numerics

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

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

@jeffhandley

@jeffhandley I moved the area back to numeric. It is parsing issue with numeric which need to consider the globalization settings. I can help with any globalization guidance as needed.

@tarekgh

OK, thanks for the course correction there, @tarekgh.

Allow whitespace after leading numeric signs and parentheses (dotnet#…

Navigation Menu

Repository navigation

Negative numeric parsing inconsistencies / can't parse standard Windows format option #101873

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Negative numeric parsing inconsistencies / can't parse standard Windows format option #101873

Description

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

Activity

dotnet-policy-service commented on May 4, 2024

danmoseley commented on May 4, 2024

dotnet-policy-service commented on Jul 20, 2024

dotnet-policy-service commented on Jul 20, 2024

tarekgh commented on Jul 20, 2024

jeffhandley commented on Jul 20, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions