Add Decimal32, Decimal64, Decimal128

[RaymondHuy]

Resolve #81376

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[huoyaoyuan]

If Int128 is not optimized, this can be optimally stored as a ReadOnlySpan of Int32/Int64 like Number.BigInteger.Pow10BigNumTable

[huoyaoyuan]

+0 and -0 should have the same hash code. The easiest way can be stripping the sign bit.

I also remember that there can be same values with different representations.

runtime/src/libraries/System.Private.CoreLib/src/System/Numerics/TotalOrderIeee754Comparer.cs

Lines 125 to 132 in 9b57a26

	else
	{
	// Equivalant values are compared by their exponent parts,
	// and the value with smaller exponent is considered closer to zero.
	// This only applies to IEEE 754 decimals. Consider to add support if decimals are added into .NET.
	return 0;
	}

[RaymondHuy]

@huoyaoyuan Thanks for your review. However this PR targets only the first phase as following: #81376 (comment) so I haven't added NegativeZero and PositiveZero. I will update GetHashCode method in the next phase.

[tannergooding]

This is on my radar to take a look at; just noting it might be a bit delayed due to other priorities for the .NET 9 release.

CC. @jeffhandley

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 10 comments.

[tannergooding]

A lot of the copilot feedback looks correct/actionable. I'm working on another review pass to make sure all the edge cases were handled.

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 9 comments.

Comments suppressed due to low confidence (2)

src/libraries/System.Runtime/ref/System.Runtime.cs:1

• The reference assembly declarations for Decimal32/Decimal64/Decimal128 appear to be missing public members that exist in the implementations (notably public override bool Equals(object? obj) and public override int GetHashCode()). Ref/impl mismatches will break API surface validation and can cause binding inconsistencies. Add these overrides (and any other public members present in the CoreLib implementations) to the ref file so the public contract matches.
  src/libraries/System.Runtime/ref/System.Runtime.cs:1
• The Decimal32 implementation is annotated with [StructLayout(LayoutKind.Sequential)], but the ref assembly declaration does not include this attribute. Since layout is part of the public interop contract, the ref should mirror it (or the implementation should drop it if not required).

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 5 comments.

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 5 comments.

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

src/libraries/System.Runtime/ref/System.Runtime.cs:1

• These new numeric types expose ToString(string?, IFormatProvider?) overloads but do not implement IFormattable. As a result, composite formatting / interpolated string format specifiers (e.g., string.Format(\"{0:N}\", value) or $\"{value:N}\") may ignore the format string and fall back to parameterless ToString(). Consider adding System.IFormattable to Decimal32/Decimal64/Decimal128 (and updating the CoreLib implementations accordingly); optionally also implement ISpanFormattable to match other numerics.

[RaymondHuy]

Hi @tannergooding I have resolved all Copilot comments. You can re-review it when you have time ;)