proposal: math: fixed decimal types

[sblackstone]

Proposal Details

I propose reconsidering the inclusion of fixed decimal types as a standard language feature.

This has been extensively discussed in these two issues:

• Issue #12127
• Issue #26699

Motivation

Currently, fixed decimal types are supported by several third-party packages, including the popular shopspring/decimal. However, a recent PR suggests that the long-term maintenance of this library is uncertain. This situation forces the community to constantly adapt to the latest maintained fork, which is a long-term burden on the ecosystem.

Decimal libraries are also crucial in various core areas, such as database drivers, validation, and testing libraries. Standardization of a fixed decimal type would ensure that:

• Database drivers can reliably unmarshal to a standardized type.
• go-playground/validator can natively validate decimal types.
• stretchr/testify can natively support decimal types.
• Passing data between libraries using different decimal implementations would no longer require conversion.

For these reasons I think it is a worth another look at one of the above proposals or a suitable alternative that supports standards and furthers interoperability.

[gabyhelp]

Related Issues

• proposal: math/big: Decimal #12127 (closed)
• proposal: Go 2: Add a Decimal Floating Point builtin type #26699 (closed)
• proposal: spec: add decimal float types (IEEE 754-2008) #19787

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

We want to avoid the trap of continually revisiting old decisions. That can easily consume all of our time and make it difficult to move forward. Is there significant new information on this topic that would lead us to make a different decision this time?

[sblackstone]

The impetus for opening this was noticing that a package my employer depends on heavily at the moment (shopspring/decimal) seems to be semi-abandoned as it's now actively pointing at forks. The previous proposals rely on the existence of these tools in the community as part of the justification for exclusion from the language.

Primitive decimal math is something that deserves a higher level of support for interoperability, security and long term stability.

[timothy-king]

rsc's comment (from 2016) when #12127 was closed: #12127 (comment) . FWIW https://pkg.go.dev/github.com/shopspring/decimal?tab=importedby lists 34,460 known importers.

[bojanz]

In my opinion, shopspring/decimal hasn't been the most optimal* decimal implementation in the ecosystem for many years now. Projects should be looking to migrate to https://github.com/cockroachdb/apd

* - in terms of performance and correctness

[sblackstone]

In my opinion, shopspring/decimal hasn't been the most optimal* decimal implementation in the ecosystem for many years now. Projects should be looking to migrate to https://github.com/cockroachdb/apd

• • in terms of performance and correctness

I think this highlights the problem of something so fundamental being relegated to library support - we are forever stuck with a fragmented ecosystem for solutions that traditionally rely on fixed decimal (e.g. finance).

[jufemaiz]

I'm here for this proposal. That Go doesn't have a native type for decimals is IMHO a deficiency of the language. Claiming that "yeah, but there's non-native packages" is an acceptance of a shortcoming of a type critical for any measurement or financial use case.

IMHO this #19787 would be the optimal spot for the discussion (and has it earmarked for Go v2, whenever that may be delivered)

[ianlancetaylor]

#19787 (which is no longer marked v2) is about decimal float types, this issue is about decimal fixed types.

[jufemaiz]

#19787 (which is no longer marked v2) is about decimal float types, this issue is about decimal fixed types.

Good catch (v2)! And 🤦🏼 on my behalf.