Move rounding into an explicit function

[sffc]

Currently, the Amount constructor and convertTo function both take rounding options.

As a result, these operations may or may not convert the input to a different data type (a string). This seems challenging for TypeScript and generally for code readability:

function convert(options) {
  let a = new Amount({ value: 1.23, unit: "meter" });
  let b = a.convertTo(options);
  return b;
}

In that code, is b a Number Amount or is it a String Amount? It can't be known without inspecting options.

By having an explicit roundTo function and removing rounding options from the constructor and convertTo, the flow of data types is much more clear.

The main downside of such a model is that you end up with an extra intermediate object: a.convertTo(convertOptions).roundTo(roundOptions) has a short-lived intermediate.

[eemeli]

How is the situation with .convertTo() any different from the situation with the consrtuctor? In this function

function foo(options) {
  let a = new Amount(1.23, options);
  return a;
}

it is similarly not possible to tell whether a is a Number Amount or a String Amount without inspecting options. Fundamentally, this is a result of accepting that the type of .value may vary.

If you do need to ensure that you're getting the value in a type that you expect, you should be using Number(a.value) or String(a.value), which will always succeed, and always get you a value in the expected type.

[sffc]

How is the situation with .convertTo() any different from the situation with the consrtuctor?

Right, it's the same issue. We should consider making .roundTo be the only function that changes the data type.

[eemeli]

So in this hypothetical structure, what would you end up with if you called .convertTo() on a BigInt Amount?

[sffc]

BigInt Amount .convertTo() would be, even more than today, something to be avoided; I am okay if it throws, but otherwise it should just do the conversion and round the result to the nearest integer.

[eemeli]

Neither of those options sounds very appealing. In either case, if you start with an Amount for which you're not sure of the type:

let a = new Amount(x, { unit: 'meter' });  // for some valid x: number | bigint | string

you'd need to do something like this to convert it to kilometers with one fraction digit:

let b = a.roundTo({ fractionDigits: 99 }).convertTo({ unit: 'kilometer' }).roundTo({ fractionDigit: 1 });

as otherwise the .convertTo() either might throw, or it might secretly round the value to an integer. The 99 is there as an optimistic marker of "enough precision" so that rounding won't surprise you.

Currently, no such tricks are required:

let b = a.convertTo({ unit: 'kilometer', fractionDigit: 1 });

Applying the change proposed here does not seem like a good idea to me.

[sffc]

if you start with an Amount for which you're not sure of the type

Your example of a pain point is only when you truly have an ambiguous numeric type. I'm not convinced that this is the common case. Tracking what type of number you have through your program is easier than ever with TypeScript. When we shifted toward polymorphic Amount, it was included in my assumption that different flavors of Amount have different flavors of behavior.

Does the committee feels that handling ambiguous numeric types in convertTo is important?

[ljharb]

I don't think we should be designing any language feature with the assumption that everyone will be using typescript.