tc39
What is the benefit of allowing extensions on special numeric literal forms?
...More specifically, when would a program's source benefit from allowing the author to write things like:
-
0b01010101010101_px,0b01010101010101_cm,0b01010101010101_m,0b01010101010101_$ -
0x0DDBA11_px,0x0DDBA11_cm,0x0DDBA11_m,0x0DDBA11_$ -
0o0666_px,0o0666_cm,0o0666m,0o0666_$
It would be nice to see real cases where a quantity of pixels are represented in hexadecimal, or quantity of centimeters in binary, or a quantity of dollars in octal.
What did you find unconvincing about https://github.com/tc39/proposal-extended-numeric-literals/blob/master/README.md#motivation ?
Cc @TabAtkins
What did you find unconvincing
Nothing in that section is relevant to my question. I'm asking something very specific and I'd appreciate it if you, as champion of this proposal, would take the time to consider my question instead of pointing me at some explainer prose that doesn't address my question at all.
@rwaldron is specifically asking about using this on special numeric forms (bin, oct, hex), not the general motivation.
(Presumably because, if we disallow it on hex, we can throw away the _ and just use units directly.)
Sorry for the delay in my response, I missed that your question was about different bases. Bases come up in ~~both~~ one of the examples:
-
User-level BigInt-like thing: BigInts are useful to have in other bases, such as very large hexadecimal values. So it's good to be able to do
0x100000000000000000000000000000_n, for example. - ~~CSS-like things: CSS uses hexadecimal by convention sometimes, for example for colors. I'm not sure if that'd be so ergonomic, though, since the syntax there starts with a hash, and we couldn't use that syntax, but I could imagine something like
element.style.color = 0xff3300_rgb--not sure if that's helpful at all though, strings may be fine for these purposes.~~
It'd seem to be a pretty odd omission to just not support other bases for something that's number-like. For this reason, BigInts support all the bases that Numbers do (even though I didn't have an especially strong use case for, say, octal in mind).
CSS's only hex usage shows up only in the context of #abcdef, and in the Typed OM we'll probably just have a constructor for it that takes the four channels as separate arguments; it's not super relevant here.
@littledan I agree with allowing the built-in BigIntLiteralSuffix for all existing bases, but there is still no compelling motivation to design this such that user extensions may be applied to all NumericLiteral forms.
User-level BigInt-like thing
In the absence of operator overloads, this isn't a compelling case. Consider the following:
// How would user-level _n be defined to do anything useful here?
0x100000000000000000000000000000_n * 1;
// What does this do?
0x100000_n * 0x100000_n;
A built-in BigInt extension (ie. BigIntLiteralSuffix) is the right solution for that, where these semantics, including operator overloading behavior, can be explicitly defined.
In the BigInt proposal, we said we were walking down the trail that we'd later try to generalize with operator overloading, extensible literals and value types. Even if this proposal doesn't have operator overloading, the idea is that it would play well with a future operator overloading proposal.
That's not to say that we have bullet-proof motivation! Maybe we should reconsider that package. But, I wrote up this proposal to try to begin walking down that road, where the idea was to have these multiple features playing well together.
