How should decimal interact with measure?

[jessealama]

The measure proposal allows JS programmers to represent numbers with a dimension (unit). It adds new capabilities to JS by exposing CLDR unit data.

As currently envisioned, a measure object contains

1. an underlying number value (e.g. a JS Number)
2. a unit
3. a precision

Example: new Measure(1.3, "gram", 2) is intended to be a datum that corresponds to 1.3 grams, with a precision of 1/10² (i.e., the true mathematical value is in the interval [1.29, 1.31]).

(Invocations of the measure API should be understood as suggestions to stimulate discussion; as of writing, measure has only recently reached stage 1 and its experimental API is very much subject to change.)

As it stands, measure is a nice companion to decimal. Fixing the unit (and especially if the unit is undefined or explicitly dimensionless), and allowing the other two parameters to vary, we have a space of measure instances that fairly closely tracks what IEEE 754 Decimal is intended to capture, namely a decimal number (understood as a mathematical value) plus a quantum.

IEEE 754 defines rules of arithmetic and other mathematical operations, and specifies, in particular, the quanta of the results of mathematical operations from the quanta of the operations arguments. As it stands, measure does not really support arithmetic on the underlying numeric values; measure's notion of arithmetic is focused on units (e.g. convering "meter" and 2 to "meter squared").

Given the conceptual overlap between measure and what we have called non-normalized, or full Decimal128, some questions arise:

• Should the measure proposal be included, at least in part, in the decimal proposal?
• Does measure give us all, or enough, of what we want out of full Decimal128?

[jessealama]

My own thinking about this:

I see measure and decimal as distinct proposals. To my eyes, measure aligns more closely with 402, though I am also open to the idea there may well be a minimal, core part of measure that could be part of 262 to which decimal could refer (see below). The explicit references to CLDR and the demand that 262 implementations need not support CLDR reinforces this line of thinking.

Measure can proceed independently of decimal. I could see a v1 of measure that supports JS Numbers (and maybe BigInts, too?) going live, regardless of the status of decimal. Decimal v1 could then build on measure v1. I can see measure supporting Decimal128 values (whether we opt for normalized or non-normalized, or both) for the underlying numeric value. Likewise, I can see that we could construct a Decimal out of a measure, provided the measure's unit is missing or explicitly dimensionless (throwing in all other cases).

[ljharb]

Distinct proposals imo, as long as the path remains open to have a Measure that contains a decimal primitive that’s just as ergonomic as one containing a number primitive.

[jessealama]

This was discussed in the February 2025 TC39 plenary. Here are the slides. @sffc also presented (slides).