In your example, is it intentional that the numeric literal 12345678901234567890n formats to a number ending in "168" instead of "890"?
12345678901234567890n.toLocaleString("en") // "12,345,678,901,234,567,168" On Thu, Apr 18, 2019 at 4:22 PM Adam Klein <ad...@chromium.org> wrote: > LGTM2 > > On Thu, Apr 18, 2019 at 4:21 PM Sathya Gunasekaran <gsat...@chromium.org> > wrote: > >> LGTM >> >> On Thu, Apr 18, 2019 at 4:02 PM Frank Tang <ft...@chromium.org> wrote: >> >>> *Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & >>> allow Intl.NumberFormat format/formatToParts to take BigInt* >>> >>> >>> Spec >>> >>> https://github.com/tc39/ecma402/pull/236 >>> >>> >>> Summary >>> >>> A Stage 3 Pull Request to change the ECMA402 that support locale >>> sensitive BigInt.prototype.toLocaleString to format the BigInt and also >>> allow Intl.NumberFormat.prototype.format and >>> Intl.NumberFormat.prototype.formatToParts to take BigInt as value. >>> Example >>> >>> BigInt(12345678901234567890).toLocaleString("de") >>> // "12.345.678.901.234.567.168" >>> >>> 12345678901234567890n.toLocaleString("en") >>> >>> // "12,345,678,901,234,567,168" >>> >>> 12345678901234567890n.toLocaleString("hi") >>> >>> // "1,23,45,67,89,01,23,45,67,168" >>> >>> 12345678901234567890n.toLocaleString("fa") >>> >>> // "۱۲٬۳۴۵٬۶۷۸٬۹۰۱٬۲۳۴٬۵۶۷٬۱۶۸" >>> >>> 12345678901234567890n.toLocaleString("fr") >>> >>> // "12 345 678 901 234 567 168" >>> >>> 12345678901234567890n.toLocaleString("th-Thai") >>> >>> // "12,345,678,901,234,567,168" >>> >>> 12345678901234567890n.toLocaleString("th-u-nu-Thai") >>> >>> // "๑๒,๓๔๕,๖๗๘,๙๐๑,๒๓๔,๕๖๗,๑๖๘" >>> >>> let nf = new Intl.NumberFormat("hi"); >>> >>> nf.format(12345678901234567890n); >>> >>> // "1,23,45,67,89,01,23,45,67,168" >>> >>> nf.formatToParts(12345678901234567890n); >>> >>> // [{type: "integer", value: "1"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "23"}, >>> // {type: "group", value: ","} >>> // {type: "integer", value: "45"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "67"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "89"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "01"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "23"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "45"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "67"}, >>> // {type: "group", value: ","}, >>> // {type: "integer", value: "890"}] >>> >>> Interoperability and compatibility risk >>> >>> The BigInt.prototype.toLocaleString was implemented as >>> BigInt.prototype.toString. This launch will make it return string >>> differently, based on the cultural conventions of the locale. Code >>> expecting the BigInt.prototype.toLocaleString behavior the same as >>> BigInt.prototype.toString will break but the chance is very low since the >>> ECMA262 specification already make it clear the toLocaleString is >>> delegating to the ECMA402 specification to specify. The >>> Intl.NumberFormat.prototype.format and formatToParts now take BigInt as >>> value instead of throwing exception. >>> >>> >>> >>> - >>> >>> Firefox:No public signals >>> - >>> >>> Edge: No public signals >>> - >>> >>> Safari:No public signals >>> - >>> >>> Web Developers:No signals >>> >>> >>> Is this feature fully tested? >>> >>> Yes; our implementation passes our own V8 tests for all the features as >>> well as tests under test262. >>> >>> - >>> >>> intl402/BigInt/prototype/toLocaleString >>> >>> <https://github.com/tc39/test262/tree/master/test/intl402/BigInt/prototype/toLocaleString> >>> - >>> >>> test/intl/bigint/ >>> <https://cs.chromium.org/chromium/src/v8/test/intl/bigint/> >>> >>> >>> Tracking bug >>> >>> https://crbug.com/v8/8699 >>> >>> >>> >>> Design Doc: >>> >>> https://goo.gl/qpRwFo >>> >>> >>> >>> Link to entry on the Chrome Platform Status dashboard >>> >>> https://www.chromestatus.com/feature/5742274625404928 >>> >>> Requesting approval to ship? >>> >>> Yes. Note that since this is a V8/JS feature, this post is just an FYI >>> to blink-dev — no signoff from Blink API owners is required. >>> >>> >>> >>> -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.