You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Interchange formats can carry finite base-10 values outside the ranges of the primitive numeric types. Callers currently preserve these values as text or maintain an ad hoc BigInteger significand and scale; neither provides shared parsing, conversion, numeric equality, or ordering.
BigNumber is an exchange type only. Arithmetic and generic-math number contracts are explicitly out of scope, leaving BigDecimal and BigFloat available for future arithmetic types. Related: #125611, #20681, #83907, #118134.
API Proposal
Parsing and formatting are invariant, and provider arguments are ignored. Numerically equivalent representations such as 1, 1.0, and 10e-1 compare equal and produce the same hash code. Signed zero preserves its sign but compares equal to zero.
Half, Int128, UInt128, and the generic parsing, formatting, and operator interfaces are available on current .NET only. The remaining surface is provided to downlevel targets, including netstandard2.0, through Microsoft.Bcl.Numerics.
Raw text preserves the wire representation but provides no numeric equality, ordering, or checked conversion.
A BigInteger plus scale requires every consumer to implement parsing and normalization.
BigDecimal or BigFloat would imply arithmetic semantics that this type deliberately does not provide.
Risks
The significand is arbitrary precision, but the prototype bounds the base-10 exponent to ±decimal.MaxValue. The downlevel implementation and current-.NET type forwarding through Microsoft.Bcl.Numerics also become part of the compatibility contract.
Usage in dotnet/runtime
No runtime consumers are changed by the prototype. Sharing parts of NumberBuffer or adding CBOR integration may be evaluated separately; primitive numeric parsing remains bespoke.
Background and motivation
Interchange formats can carry finite base-10 values outside the ranges of the primitive numeric types. Callers currently preserve these values as text or maintain an ad hoc
BigIntegersignificand and scale; neither provides shared parsing, conversion, numeric equality, or ordering.BigNumberis an exchange type only. Arithmetic and generic-math number contracts are explicitly out of scope, leavingBigDecimalandBigFloatavailable for future arithmetic types. Related: #125611, #20681, #83907, #118134.API Proposal
Parsing and formatting are invariant, and provider arguments are ignored. Numerically equivalent representations such as
1,1.0, and10e-1compare equal and produce the same hash code. Signed zero preserves its sign but compares equal to zero.Half,Int128,UInt128, and the generic parsing, formatting, and operator interfaces are available on current .NET only. The remaining surface is provided to downlevel targets, includingnetstandard2.0, throughMicrosoft.Bcl.Numerics.Prototype: eiriktsarpalis@9599cd1
API Usage
Alternative Designs
BigIntegerplus scale requires every consumer to implement parsing and normalization.BigDecimalorBigFloatwould imply arithmetic semantics that this type deliberately does not provide.Risks
The significand is arbitrary precision, but the prototype bounds the base-10 exponent to
±decimal.MaxValue. The downlevel implementation and current-.NET type forwarding throughMicrosoft.Bcl.Numericsalso become part of the compatibility contract.Usage in dotnet/runtime
No runtime consumers are changed by the prototype. Sharing parts of
NumberBufferor adding CBOR integration may be evaluated separately; primitive numeric parsing remains bespoke.Note
This proposal was drafted with GitHub Copilot.