Do we support hexadecimal literals?

[littledan]

If so, the d suffix doesn't work...

[qzb]

It would be confusing not to, since BigInt supports them.

[caiolima]

I'm not in favor of allowing this, at least in the scope of this proposal. Hexadecimals are majorly used with integer in mind and I don't see compelling use cases for 0x2.5m. If we decide to stick with m suffix, we have room to support hexadecimal literals in the future.

[ljharb]

If Decimal can’t transparently interoperate with BigInt, then I’d very much need to represent integer Decimal hexadecimals so i could combine them with other Decimals.

[littledan]

@ljharb Sure, but would it make sense to use hexadecimal for those? If you're multiplying a price by the number of items in the shopping cart (to caricature an example that doesn't actually make sense, since those wouldn't be literals... but in general my intuition is that this is useful for "copies of something"), it doesn't make sense to me. I think hexadecimal is more useful when you're thinking about binary and computers than copies of real things.

[ljharb]

My hope would be to use Decimals and BigInt for everything and stop using Number entirely.

[littledan]

Right, BigInt supports hexadecimal literals; I think the way that BigInt supports binary operations (and decimal doesn't) makes it a better fit. Let's discuss the "use for everything" concept in other threads, especially #39.

[ljharb]

That’s fine as long as there’s transparent interop between Decimal and BigInt. If not, Decimal needs to subsume BigInt.

[littledan]

See #20 -- The current proposal doesn't include bitwise operators, so it doesn't subsume BigInt in its current form. Could you explain your stance on why "subsume or transparent interop" is a requirement in #39, where we're trying to answer the transparent interop question?

[tabatkins]

I think the options are:

1. Don't support hex at all; if you want to construct a Decimal from a hex literal you can write BigDecimal(0xabcd).
2. Support hex (and binary, and octal) literals with an m suffix. This implies that you can only represent integers.
3. Support hex (/binary/octal) literals with an m suffix, defining a new production that allows for non-integer representations, like 0x2.5m (to mean 2 + 5/16).

I think 3 is totally unnecessary. Non-decimal fractions are exceedingly rare in practice, especially as literals, so I don't think they remotely justify adding a new type of production, particularly when most such literals would produce an infinite decimal (and thus would lose detail in precise the same way that most decimal fractions today lose precision, and which Decimal is precisely designed to prevent).

I think 2 is a little weird, tho, that you have a new type designed explicitly to support decimal non-integers, and have some syntaxes for it that explicitly do not support non-integers. I also question the common-ness of the use-case - how often do you write a hex (/binary/octal) literal that is then meant to directly interact with potentially non-integer base-10 numbers? In my experience those syntaxes are almost always used to interact with byte-based stuff and/or bit-manipulation.

So I think we can safely get away with not allowing it and just relying on the BigDecimal() converter, for the likely extremely rare cases it's needed.