⇒ If you think the “sensible default behavior is to preserve precision“ I think you would have to call for (at least) rational as the default non-integer integral type. (If you think of √2 as a literal, it gets more complicated. In the end, you might have to use a representation that’s similar to that used in computer algebra systems)
Edit: you could also require constants that do have an exact representation in your floating point format. That would be annoying, too, though, but maybe not too annoying if you had a way to specify “the number closest to this one”, say by requiring one to write ~2.1~ instead of 2.1
IMO decimal rounding of those fractions, while not ideal, is a lot more understandable to a typical person. If 1/3 * 3 = 0.99999999999999999 that's annoying, but not crazy in the same way that the floating-point equivalent is.
(Also, "correctness" seems like the wrong word: making rationals the default type would give you perfectly precise literals, but you'd immediately lose that once you perform almost any operation on them.)
Anything with a REST api or JSON doesn’t have native support for Decimals, so to use them you have to represent them in component form as an object or as a string.
Ints just make that easer at the slight cost at display time. Stripe is a good example of this.
> Otherwise you're applying that exponent everywhere you use the value, whether you display it or use it in a mathematical expression.
Slightly disagree, I think it’s only when displaying you have to convert to a “human readable” decimal form. They don’t need converting to Decimal for processing.
It’s also worth noting there are actually two none decimal currency’s still in use:
“Today, only two countries have non-decimal currencies: Mauritania, where 1 ouguiya = 5 khoums, and Madagascar, where 1 ariary = 5 iraimbilanja.”
This is a very slight nitpick (that might be wrong) but I think it's perfectly in line with the JSON specification to interpret JSON numbers as decimals.
"JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange."
https://www.ecma-international.org/wp-content/uploads/ECMA-4...
https://datatracker.ietf.org/doc/html/rfc7159
And most JSON parsers allow you to extend and change how types are handled. I think however from a developer point of view by standardising on ints you reduce the risk of making a mistake in your implementation.
I think the point is though that as long as your system doesn't need to handle fractions of a cent/pence/etc then using them as the base representation and only doing integer math makes the system simpler. It moves the complexity of currency to the display layer away from the business layer. Obviously there are times when you need to be able to handle smaller units and a decimal type would be correct there.