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.

Reply via email to