Honour AllowDecimalPoint, AllowExponent and AllowLeadingSign in Parse [patch]

[matt-edmondson]

Fixes #132

Problem

Parse(ReadOnlySpan<char>, NumberStyles, IFormatProvider?) accepted a decimal separator, an exponent and a leading minus sign whatever the style said. As a result, "1.5" and "1e5" parsed under NumberStyles.Integer, "-5" parsed under NumberStyles.None, and "1e 5" parsed under Float. Callers that validate input through INumberBase<T>.TryParse with a narrow style therefore received values they had excluded, which every BCL numeric type rejects.

Change (PreciseNumber.cs)

• The decimal separator is read only when the style includes AllowDecimalPoint.
• e/E is read only when the style includes AllowExponent. The exponent digits are now parsed with NumberStyles.AllowLeadingSign instead of Integer, so whitespace inside the exponent is rejected.
• ReadLeadingSign now reads neither sign unless the style includes AllowLeadingSign. Before, it already applied this rule to the positive sign. That includes the ASCII hyphen kept for cultures that use U+2212.

Behavior change (for the changelog): callers passing NumberStyles.Integer or None now get a FormatException, or false from TryParse, for fractional, exponent or signed text. decimal behaves the same way. The default Parse(string, provider) and TryParse(string, provider, out) overloads use NumberStyles.Any, so they are unaffected.

Tests (PreciseNumberParseCultureTests)

• TryParse_AcceptsWhatDecimalAccepts compares the result with decimal.TryParse for every input in the issue's table. It also covers inputs that must keep working: "1.5" with Float, "-1.5e-3" with Float and Any, "1,234.5" with Any, "-5" with Integer, and "1e+5" with Float.
• Parse_ThrowsForWhatTheStyleDoesNotAllow checks the Parse (throwing) path for the same rejected inputs.
• Parse_WithoutAStyleStillReadsFractionsExponentsAndSigns checks the default overload.
• Parse_ReadsACulturesNegativeSignOnlyWhenTheStyleAllowsIt checks the U+2212 sign and the hyphen fallback under None and Float.

With the PreciseNumber.cs change reverted, 8 of these tests fail. With the change, the full suite passes locally: 469 of 469. dotnet format --verify-no-changes reports one IDE0001 finding at PreciseNumber.cs:2078. It is already on main and this PR doesn't touch that line.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FtvW1bPVVfCTF7fCWpeyRE

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud