Format specifier for BigInt

[shisama]

Chrome 68 supports BigInt and also Node.js v10 supports it with --harmony-bigint flag. But console.log doesn't support BigInt in them.

Chrome 68

> console.log("%d", 1180591620717411303424n)
NaN
> console.log("%i", 1180591620717411303424n)
NaN

Node.js v10.7.0 with --harmony-bigint

> console.log("%d", 1180591620717411303424n)
1.1805916207174113e+21
> console.log("%i", 1180591620717411303424n)
1.1805916207174113e+21

I think expected result is

> console.log("%d", 1180591620717411303424n)
1180591620717411303424n
> console.log("%i", 1180591620717411303424n)
1180591620717411303424n

However, spec shows %d or %i uses %parseInt%(element, 10) for type conversion.
What specifier is the best for BigInt? Has this already been discussing?

[silverwind]

Keep in mind that Node.js is currently violating the spec for the %d specifier where it uses the Number constructor which outputs those undesired scientific prefixes. The specced parseInt on the other hand can output series of digits for BigInt because its toString method which does not include the notion of a scientific notation.

So I think, we may not even need a spec change.

[silverwind]

Actually upon deeper investigation parseInt is also unsuitable for BigInt because it has NumberToString baked into it which represents everything above 1e21 using exponents.

So I think we'd actually need a console spec change, I see two options:

1. Let %i and %d also handle BigInt. This would introduce different behavior depending on the type.
2. Introduce a new %I dedicated for BigInt to retain a 1:1 mapping of type to conversion function.

[terinjokes]

I believe the issue isn't NumberToString (since BigInt isn't a Number), but parseInt's call to ToInt32.

%parseInt%(1180591620717411303424n, "10") <- 1.1805916207174113e21
  ToString(1180591620717411303424n) <- "1180591620717411303424" (https://tc39.github.io/proposal-bigint/#sec-tostring-applied-to-the-bigint-type)
  ToInt32("1180591620717411303424") <- 1.1805916207174113e21
   ToNumber("1180591620717411303424") <- 1.1805916207174113e21

I would prefer to define %d and %i specifiers to handle BigInt. The current description does not state int32, but instead "Element which substitutes is converted to an integer" which is vague enough.

On the other hand, BigInt.ToNumber() is defined to throw an error, and I'm unsure if using the same formatters will cause confusion with developers.

[domenic]

My two cents: agreed handling BigInt is good. Probably https://console.spec.whatwg.org/#formatter step 3.2 should add another special-case for BigInt, like it currently does for Symbol. Also the third column of https://console.spec.whatwg.org/#formatting-specifiers should be updated I guess, not sure how though.

[silverwind]

Also the third column of https://console.spec.whatwg.org/#formatting-specifiers should be updated

Maybe add a additional column before it for the source type. This could also include the Symbol special case.

[fmartin5]

Options (1) and (2) do not look mutually exclusive: the %d and %i specifiers could handle BigInt values by returning NaN just like they do for Symbol values, while the proposed %I specifier could still produce specific results for BigInt formatting.

[shisama]

If new specifier is necessary for BigInt, the proposed %I looks good.

[paulirish]

In Chrome, we just allowed console.log("%d") to support BigInts:
https://chromium-review.googlesource.com/c/chromium/src/+/1169777 cc @ak239

If this group decides we need different behavior, we can align.

[terinjokes]

I don't mind expanding %i and %d to support BigInt, and updating our table to include it.

Paul, does Chrome have interest in also supporting %i?

Do we have input from Firefox, Safari, or Edge?

[alexkozy]

In Chrome we support both and both of them support BigInt.

[terinjokes]

@ak239 thanks for confirming. Gerrit wasn't loading well for me on Muni.

[shisama]

@paulirish @ak239 Thanks. Now I confirmed console.log("%d", 1n); and console.log("%i", 1n); print 1n on console in Chrome Canary(version 70.0.3521.0).

[silverwind]

The Chrome implementation appends the n suffix to the formatted number but I think it would be more generally useful to hide such implementation details and output just the number.