Retain numeric types across convertTo operations

[sffc]

If you start with a Number Amount, it doesn't seem right to pull a precision out of thin air during convertTo and return it as a IntlMV Amount. You should get back another Number Amount that contains the raw result of a floating point arithmetic operation.

If you started with a IntlMV Amount, then you should get back another IntlMV Amount while retaining precision according to #82.

In other words, the only operation that should transfer you from a floating-point Number to an IntlMV is when setting maximum significant or fraction digits (with a rounding mode), not unit conversion.

[eemeli]

What is the use case that's served by retaining the Number type through conversion?

If we apply such a change, would you say that BigInt values also stay as BigInts through conversion?

[sffc]

What is the use case that's served by retaining the Number type through conversion?

I don't understand this question. This is about correctness, not use cases. What is the use case that's served by pulling a precision out of thin air and converting the Number to a string through conversion?

If we apply such a change, would you say that BigInt values also stay as BigInts through conversion?

Good question. I'd say it depends on whether we consider a BigInt to be a point on the number line (like Number) or a quantity with integer precision (like String Decimal).

[ljharb]

BigInt is a point on the Number line - it's got no limit and is a precise integer, per spec.

[eemeli]

What is the use case that's served by retaining the Number type through conversion?

I don't understand this question. This is about correctness, not use cases. What is the use case that's served by pulling a precision out of thin air and converting the Number to a string through conversion?

A key tenet of the current design is that we've not identified a non-formatting use case for unit conversion. Therefore, it makes sense for us to build unit conversion in a manner supporting specifically the presentation of the conversion result to a user. This allows us to assume that it's fine to present the result as a numeric string, and to apply the same defaults for precision as used by Intl.NumberFormat.

Hence my question about the use case that you're looking to serve here, as the one we've identified for this does not need it.

[sffc]

A key tenet of Intl design is that properties impacting the display of an item (precision, calendar system, ...) are retained when available, applied explicitly, or else defaulted at the last moment.

Hallucinating formatting precision upon conversion violates two of those tenets: they aren't explicit, and they aren't at the last moment.