[matt-edmondson]

PreciseNumberExtensions.ToPreciseNumber accepted only three kinds of input: PreciseNumber itself, IBinaryInteger* types and IFloatingPoint* types. Any other INumber<T> threw NotSupportedException, including one that implements TryConvertToChecked<PreciseNumber>, such as ktsu.SignificantNumber. So these calls threw while s.CompareTo(p) worked:

• p.CompareTo(s)
• p.Clamp(s, s)
• s.Clamp(lo, hi), through SignificantNumber.Clamp

Change

For a type in neither family, TryCreate now falls back to INumberBase<PreciseNumber>.CreateChecked. That method asks PreciseNumber, then the input type. It reports failure only on the NotSupportedException that CreateChecked throws when neither side can convert. Any other exception, such as an OverflowException, still propagates, as it would from CreateChecked. The integer and floating-point fast paths are unchanged.

Tests

• SelfConvertingNumber is a new test-only INumber<T> backed by decimal. It is in neither interface family. Its CanConvert flag decides whether TryConvertToChecked<PreciseNumber> succeeds.
• TestToPreciseNumberAcceptsATypeThatConvertsItself checks three things:
  • ToPreciseNumber() equals CreateChecked;
  • CompareTo<TInput> works;
  • Clamp<TNumber> works.
• TestToPreciseNumberStillRejectsATypeThatCannotConvert checks that ToPreciseNumber, CompareTo and Clamp still throw NotSupportedException when the type can't convert.
• Without the fix, the first test fails with NotSupportedException. The full suite passes: 588 tests.

CLAUDE.md's description of PreciseNumberExtensions now covers the fallback.

Downstream, SignificantNumber's p.CompareTo(s) and s.Clamp(lo, hi) will work once it picks up this package (see ktsu-dev/SignificantNumber#145 and #149).

Fixes #188

---

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