[v8-users] Re: [blink-dev] Intent to Implement and Ship: Let all early errors be SyntaxErrors

[Sathya Gunasekaran]

On Mon, Jun 24, 2019 at 11:49 PM Adam Klein  wrote:
>
> On Fri, Jun 21, 2019 at 12:09 AM Yoav Weiss  wrote:
>>
>> OK. Do you typically get those bug reports on Canary, Beta, or once the 
>> feature in question have hit stable?
>> (This is more of a generic question: I don't think this particular feature 
>> should block on putting counters in place if this is how V8 typically rolls. 
>> I just want to better understand your workflow regarding deprecations and 
>> changes)
>
>
> I don't think this has been tracked systematically (the number of bug reports 
> due to V8 web-exposed-API changes in the last couple years is pretty small, 
> probably ~5-10), but I'd say Stable is most common, unfortunately.
>
> Sathya has been working more actively in this area recently than I have, and 
> might have other thoughts.
>

This matches my experience shipping recent breaking changes -- Stable
is the best bet, there's not much coverage from canary or beta.

Thanks,
--Sathya

>>>
>>>
>>> On Mon, Jun 17, 2019 at 9:42 PM Yoav Weiss  wrote:
>>>>
>>>> LGTM2
>>>>
>>>> Do we have metrics in place in case we got it wrong and sites do rely on 
>>>> eval's error types in weird and unexpected ways? Or we're relying on bug 
>>>> reports to alert us of that?
>>>>
>>>> On Tue, Jun 18, 2019 at 6:34 AM Chris Harrelson  
>>>> wrote:
>>>>>
>>>>> I see. Given that lack of interop, I do agree that probably sites are not 
>>>>> relying on the current behavior, and if they are then they are likely not 
>>>>> interoperable.
>>>>>
>>>>> LGTM1 to try.
>>>>>
>>>>> On Mon, Jun 17, 2019 at 3:02 PM Ross Kirsling  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 17, 2019, 11:42 Chris Harrelson  wrote:
>>>>>>>
>>>>>>> Hi again,
>>>>>>>
>>>>>>> Sorry for the slow response.
>>>>>>>
>>>>>>> On Thu, Jun 6, 2019 at 7:17 AM Sathya Gunasekaran 
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't expect to see code that special cases against ReferenceError
>>>>>>>> in the wild especially for just early errors. I expect to see code
>>>>>>>> that handles both ReferenceErrors and SyntaxErrors. Since we're not
>>>>>>>> adding a new type of error, I wouldn't expect to see any breakage.
>>>>>>>
>>>>>>>
>>>>>>> Do you have any data to support this? Are there any use counters for 
>>>>>>> how often this situation might occur? e.g. what fraction of pages 
>>>>>>> trigger ReferenceErrors?
>>>>>>> Also, have any other browsers shipped this change yet?
>>>>>>
>>>>>>
>>>>>> The concern here is purely around *early* ReferenceError. Since 
>>>>>> ReferenceError has been ambiguous between parse time and runtime, it 
>>>>>> would have been extremely difficult/fragile to use this information—as 
>>>>>> mentioned, one would need to string-match on error messages. (I think 
>>>>>> folks are hung up on the phrase "observable concern", but I meant this 
>>>>>> to indicate that there's something non-cosmetic to be *gained*, not that 
>>>>>> there's worry about breakage.)
>>>>>>
>>>>>> The new behavior shipped in Safari TP 83 three weeks ago, and it's 
>>>>>> important to note that the major engines were not previously in 
>>>>>> alignment anyway. V8 was conforming to spec, but JSC actually had *late* 
>>>>>> ReferenceError for all four cases and SM was split (`0++` and `0--` were 
>>>>>> early SyntaxError while `0 = 0` and `0 += 0` were early ReferenceError).
>>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "blink-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to blink-dev+unsubscr...@chromium.org.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhQtWJoxxi3PwfutmSbZFJGyNkKpgD1OeMFDM6%3D2sA4bw%40mail.gmail.com.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcKV93MirncPshaX9z29%3D5-0aBcecEOJ-Z%3D0zZE1%2BQb%3D7w%40mail.gmail.com.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAMd%2BM7z-0yrxhQnNTD08VjSoV-HGsD5_FHAED0TX-AGiyiWDpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Implement and Ship: Let all early errors be SyntaxErrors

[Sathya Gunasekaran]

On Thu, Jun 6, 2019 at 11:29 AM Yoav Weiss  wrote:
>
>
>
> On Tue, Jun 4, 2019 at 5:30 PM Ross Kirsling  wrote:
>>
>> Contact email
>>
>> rkirsl...@gmail.com
>>
>>
>> Explainer
>>
>> https://github.com/tc39/ecma262/pull/1527#issuecomment-489228449
>>
>>
>> Spec
>>
>> https://github.com/tc39/ecma262/pull/1527
>>
>>
>> Summary
>> Replace all early ReferenceErrors with early SyntaxErrors.
>>
>> Motivation
>> The spec has been inconsistent with respect to the "early ReferenceError" 
>> notion: only update/assignment expressions (e.g. `0++`, `0 = 0`) have had 
>> early ReferenceErrors, while other invalid assignment target cases like `[0] 
>> = []` and `for (0 of []) {}` have been early SyntaxError.
>>
>> Furthermore, this becomes an observable concern with eval: if eval throws a 
>> ReferenceError, the user has had no way to know whether the code was 
>> actually executed or simply parsed (short of matching on error message 
>> strings).
>>
>> Risks
>> Interoperability
>> None. This reached consensus at TC39, it received explicit positive feedback 
>> from all major engines, and it is already shipping in Safari TP 83.
>>
>> Compatibility
>> None expected. This simply changes a parse-time error type. As mentioned 
>> above, it would have been nearly impossible for userland code to depend on 
>> this typing.
>
>
> I'm confused. Above you say "this becomes an observable concern with eval" 
> which seems to contradict your "Compatibility" section.

I think Ross is trying to say that it becomes *less* of a concern with
this change. Previously, with a ReferenceError you wouldn't know if it
was an early error or not. But now, with this change, you will know
for sure that a ReferenceError is not an early error. This change
makes everything more consistent.

> Can you elaborate on the observability of this change and how would code that 
> depends on it may look like? (if it can be observed)

The observability of this change is that all early errors that were
ReferenceErrors are now SyntaxErrors. If previously you had code that
eval'd something that resulted in a ReferenceError, it will now be a
SyntaxError.

In the following example,
```
try {
  eval('0 = 0');
} catch (e) {
  if (e instanceof ReferenceError) {
doFoo();
  } else {
doBar();
  }
}
```

this change will run doBar, instead of doFoo.

I don't expect to see code that special cases against ReferenceError
in the wild especially for just early errors. I expect to see code
that handles both ReferenceErrors and SyntaxErrors. Since we're not
adding a new type of error, I wouldn't expect to see any breakage.

Thanks,
--Sathya



>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>> Yes.
>>
>> Is this feature fully tested by Test262?
>> Yes: https://github.com/tc39/test262/pull/2147
>>
>> Link to entry on the feature dashboard
>> https://www.chromestatus.com/feature/5756460363415552
>>
>> Requesting approval to ship?
>> Yes.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHnZyqBi3XLxmrsCUVt1tcOirf4rQzz_RwzHh89%2B0zCk0B-e6w%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiHuLpw%3D7wU8Hya4%2B-0X6MNcUm5Pvbn4Xwy-u9PSp%3DbCw%40mail.gmail.com.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAMd%2BM7zjnOFi1L_S%3Dd_EDo%3D%3D9tiL9dpdFfwYPfvgQwsXeYDjsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Promise.{all, race, allSettled} optimization

[Sathya Gunasekaran]

Contact emails

gsat...@chromium.org

Explainer

https://github.com/tc39/proposal-promise-allSettled/pull/40

https://github.com/tc39/ecma262/issues/1505

Spec

https://github.com/tc39/ecma262/pull/1506/files

https://github.com/tc39/proposal-promise-allSettled/pull/40/files

Summary

Promise.{all , race
, allSettled
} lookup the
constructor of the receiver on every iteration of the loop. Instead, this
change makes the lookup happen only once outside the loop.

Motivation

To optimize away the Get and Call of the resolve method on the constructor,
I'd have to check the constructor to see if its resolve method has been
modified or not. If it's not been modified, I can directly call (or even
inline) the builtin %PromiseResolve%, saving the lookup and call overhead
for faster performance.

Without this patch, I would have to check against the constructor for every
iteration of the loop before going to the fast path. With this patch, I can
do a check against the constructor just once at the beginning.

The change in behavior with this patch is that if you modify the
constructor's resolve property in the middle of iterating the iterable
argument, then it is not observed.

Risks

Interoperability and Compatibility

There is a very small risk of interop and web compatibility in the case of
Promise.all and Promise.race, as we are modifying the behavior of methods
that have been shipping for a while. There is no risk of interop or web
compat with Promise.allSettled as it is a new proposal.

I expect the risk to be very low considering the surprising side-effecting
nature of changing the resolve method *while* iterating over the argument
or if there is a user installed ‘resolve’ getter that side effects.

Unfortunately it’s not possible to use counters to determine if this will
break or not -- we can’t count the side effects of calling a method. We can
only determine if the resolve method has been patched or not, but that’s
not fully sufficient to determine the risk.

Given the very low risk of this surprising behavior, I’d like to ship this
to determine if there is any breakage.

Ergonomics

N/A

Activation

N/A


Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?

Yes.

Debuggability

This doesn’t change any of the debugging functionality of Promises.

Is this feature fully tested by web-platform-tests
?
Link to test suite results from wpt.fyi.

V8 passes all the test262 tests: https://github.com/tc39/test262/pull/2131

Entry on the feature dashboard 

https://www.chromestatus.com/feature/5171235300311040

Requesting approval to ship?

Yes

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Promise.allSettled

[Sathya Gunasekaran]

Contact Emails:
gsat...@chromium.org

Spec:
https://tc39.github.io/proposal-promise-allSettled/

Summary:
Promise.allSettled returns a promise that is fulfilled with an array
of promise state snapshots, but only after all the original promises
have settled, i.e. become either fulfilled or rejected.

Interoperability and compatibility risk:
This stage 3 proposal introduces a new static method on the Promise
constructor. There is very low compat risk.

Firefox: In development
Safari: No signals
Edge: No signals

Is this feature fully tested?
Yes, this feature passes V8's own mjsunit tests as well as all the
test262 tests.

Tracking bug:
https://bugs.chromium.org/p/v8/issues/detail?id=9060

Link to entry on the Chrome Platform Status dashboard
https://www.chromestatus.com/feature/5547381053456384

Requesting approval to ship?
Yes. Note that since this is a V8/JS feature, this post is just an FYI
to blink-dev — no sign off from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & allow Intl.NumberFormat format/formatToParts to take BigInt

[Sathya Gunasekaran]

LGTM

On Thu, Apr 18, 2019 at 4:02 PM Frank Tang  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
>
> 
>-
>
>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-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intend to Ship: DateTimeFormat dateStyle & timeStyle options

[Sathya Gunasekaran]

LGTM

On Mon, Apr 1, 2019 at 12:13 PM Sathya Gunasekaran 
wrote:

>
>
> On Fri, Mar 29, 2019 at 7:41 AM Frank Tang  wrote:
>
>> Spec
>>
>> https://github.com/tc39/proposal-intl-datetime-style/
>>
>> Summary
>>
>> A Stage 3 proposal that adds two options to Intl.DateTimeFormat:
>> dateStyle and timeStyle. These options give a compact way to request the
>> appropriate, locale-specific way to ask for a date and time of given lengths
>> Example
>>
>> let o = new Intl.DateTimeFormat("en" , {
>>   timeStyle: "short"
>> });console.log(o.format(Date.now())); // "13:31"
>> let o = new Intl.DateTimeFormat("en" , {
>>   dateStyle: "short"
>> });console.log(o.format(Date.now())); // "21.03.2012"
>> let o = new Intl.DateTimeFormat("en" , {
>>   timeStyle: "medium",
>>   dateStyle: "short"
>> });console.log(o.format(Date.now())); // "21.03.2012, 13:31"
>>
>>
>>
>> Interoperability and compatibility risk
>>
>> The two new options added to Intl.DateTimeFormat is new and should have
>> no risk to break pre-existing javascript code.
>>
>>-
>>
>>Firefox:Public support
>><https://bugzilla.mozilla.org/show_bug.cgi?id=1329904>
>>-
>>
>>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.
>>
>> test/intl/date-format/constructor-date-time-style.js
>> test/intl/date-format/constructor-date-time-style-order.js
>> test/intl/date-format/property-override-date-time-style.js
>> test/intl/date-format/constructor-date-style-order.js
>> test/intl/date-format/property-override-date-style.js
>> test/intl/date-format/constructor-time-style-order.js
>> test/intl/date-format/property-override-time-style.js
>>
>>
> What about test262 tests?
>

Test262 tests for this has landed and V8 passes all of them:
https://chromium.googlesource.com/v8/v8/+/96c1a8835f04859fccf1d183c0f545cab7affe1d#


>
>
>> Tracking bug
>>
>> https://crbug.com/v8/8702
>>
>>
>> Design Doc:
>>
>> https://goo.gl/v7n7zV
>>
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/features/5091631933947904
>>
>>
>>
>> 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-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intend to Ship: DateTimeFormat dateStyle & timeStyle options

[Sathya Gunasekaran]

On Fri, Mar 29, 2019 at 7:41 AM Frank Tang  wrote:

> Spec
>
> https://github.com/tc39/proposal-intl-datetime-style/
>
> Summary
>
> A Stage 3 proposal that adds two options to Intl.DateTimeFormat: dateStyle
> and timeStyle. These options give a compact way to request the appropriate,
> locale-specific way to ask for a date and time of given lengths
> Example
>
> let o = new Intl.DateTimeFormat("en" , {
>   timeStyle: "short"
> });console.log(o.format(Date.now())); // "13:31"
> let o = new Intl.DateTimeFormat("en" , {
>   dateStyle: "short"
> });console.log(o.format(Date.now())); // "21.03.2012"
> let o = new Intl.DateTimeFormat("en" , {
>   timeStyle: "medium",
>   dateStyle: "short"
> });console.log(o.format(Date.now())); // "21.03.2012, 13:31"
>
>
>
> Interoperability and compatibility risk
>
> The two new options added to Intl.DateTimeFormat is new and should have no
> risk to break pre-existing javascript code.
>
>-
>
>Firefox:Public support
>
>-
>
>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.
>
> test/intl/date-format/constructor-date-time-style.js
> test/intl/date-format/constructor-date-time-style-order.js
> test/intl/date-format/property-override-date-time-style.js
> test/intl/date-format/constructor-date-style-order.js
> test/intl/date-format/property-override-date-style.js
> test/intl/date-format/constructor-time-style-order.js
> test/intl/date-format/property-override-time-style.js
>
>
What about test262 tests?


> Tracking bug
>
> https://crbug.com/v8/8702
>
>
> Design Doc:
>
> https://goo.gl/v7n7zV
>
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/features/5091631933947904
>
>
>
> 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-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [blink-dev] Re: [v8-users] Intent to Ship: Numeric separators

[Sathya Gunasekaran]

(retrying from @chromium.org account)

On Thu, Mar 15, 2018 at 2:25 PM Adam Klein  wrote:
>
> There's a possible conflict between this feature and another proposal, 
> Extended Numeric Literals. The issue, 
> https://github.com/tc39/proposal-extended-numeric-literals/issues/7, should 
> be addressed at next week's TC39 meeting, and I'd like to see it settled 
> before shipping this in V8.

This issue has been resolved.

> On Thu, Mar 15, 2018 at 5:02 PM, Sathya Gunasekaran  
> wrote:
>>
>> Note that this is a v8/JavaScript feature, so this post is just an FYI for 
>> blink-dev — no sign-off from Blink API owners is required.
>>
>>
>> Contact Emails:
>> gsat...@chromium.org
>> b...@b6n.ch
>>
>> Spec:
>> https://tc39.github.io/proposal-numeric-separator/
>>
>> Summary:
>> This feature enables developers to make their numeric literals more readable 
>> by creating a visual separation between groups of digits. Using underscores 
>> (_, U+005F) as separators helps improve readability for numeric literals, 
>> for ex: 1_000_000_000.
>>
>> Interoperability and Compatibility Risk:
>> This is a Stage3 feature in the TC39 process. Previously this was a 
>> SyntaxError so there is no compat risk.
>>
>> Safari and Edge have not implemented this feature. This is under development 
>> in Firefox.
>>
>> V8 tests as well as test262 tests pass.
>>
>> Tracking bug:
>> https://bugs.chromium.org/p/v8/issues/detail?id=7317
>>
>> Chromestatus entry:
>> https://www.chromestatus.com/feature/5829906369871872
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcLP3jm-TDH9FkrwvtrYiz4%2BEGYvHAQRg5UP98PQHKuRXw%40mail.gmail.com.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to ship: Intl.Locale

[Sathya Gunasekaran]

LGTM2

On Tue, Feb 19, 2019 at 9:59 PM Frank Tang (譚永鋒)  wrote:

> Spec
>
> https://tc39.github.io/proposal-intl-locale/
>
> Summary
>
> A Stage 3 proposal that introduces a new standard built-in property of the
> Intl object, which allows the following:
>
>-
>
>Parsing and manipulating the language, region and script of a locale
>-
>
>Reading or writing the Unicode extension tags in a locale
>-
>
>A serializable, standard format to store user locale preferences for
>use in Intl APIs rather than a combination of language and options bag.
>-
>
>For future proposals, a Locale class can be used for an interface to
>get at various kinds of locale data, including likely subtags, first day of
>the week, various display names, etc.
>-
>
>Allow Intl objects to take Intl.Locale object as item in the locales
>parameter in addition to the pre-existing string form.
>
> Example
>
> let loc = new Intl.Locale("pl-u-hc-h12", {
>
>  calendar: 'gregory'
>
> });
>
> console.log(loc.language); // "pl"
>
> console.log(loc.hourCycle); // "h12"
>
> console.log(loc.calendar); // "gregory"
>
> console.log(loc.toString()); // "pl-u-ca-gregory-hc-h12"
>
> // use Intl.Locale in Intl.DateTimeFormat constructor
>
> let df = new Intl.DateTimeFormat([loc, "pl"]);
>
> // Add likely subtags to the locale
>
> console.log(loc.maximize().toString()); //
> "pl-Latn-PL-u-ca-gregory-hc-h12"
>
> // Remove likely subtags from locale
>
> console.log((new Intl.Locale("zh-Hant-TW")).minimize().toString()) //
> "zh-TW"
>
> console.log((new Intl.Locale("zh-Hans-CN")).minimize().toString()) // "zh"
>
>
>
> Interoperability and compatibility risk
>
> The Intl.Locale is new and should have no risk to break pre-existing
> javascript code.
>
>-
>
>Firefox:In development
>
>-
>
>Edge:In development 
>-
>
>Safari:No public signals
>-
>
>Web Developers:No signals
>
>
> Is this feature fully tested?
>
> Yes; our implementation passes our own V8 tests as well as the Test262
> tests for all the features. To pass all the test262 tests, V8 is based on
> the latest ICU version 63 with 3 bug fixing patches (uloc1.patch
> ,
> uloc2.patch
> ,
> uloc3.patch
> ),
> which are part of the coming ICU 64 (schedule to be released on March 29,
> 2019) release.
>
> Tracking bug
>
> https://crbug.com/v8/7684
>
>
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/feature/4936310187884544
>
>
>
> 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.
>
>
> --
> Frank Yung-Fong Tang
> 譚永鋒 / 
> Sr. Software Engineer
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to ship: Private class fields

[Sathya Gunasekaran]

Contact Emails

gsat...@chromium.org


Spec

https://github.com/tc39/proposal-class-fields


Summary (taken from our WebFu article
)



This private fields proposal provides encapsulation: If you're using an
instance of a class, you cannot reference that class's private fields from
outside the class body. You can only reference private fields from within
the class that defines them.


The new private fields syntax is similar to public fields, except you mark
the field as being private by using #
.
You can think of the # as being part of the field name:


class IncreasingCounter {

 #count = 0;

 get value() {

   console.log('Getting the current value!');

   return this.#count;

 }

 increment() {

   this.#count++;

 }

}


Private fields are not accessible outside of the class body:


const counter = new IncreasingCounter();

counter.#count;

// → SyntaxError

counter.#count = 42;

// → SyntaxError


This intent to ship includes private static fields as well:


class ClassCounter {

 static #count = 0;

 static increment() {

   this.#count++;

 }

}

ClassCounter.#count;

// → SyntaxError

ClassCounter.increment();



Interoperability and compatibility risk

This stage 3 proposal introduces new syntax that was previously a
SyntaxError. There’s very low web compat risk.


Firefox: In development


Safari: In development 

Edge: No signals


Is this feature fully tested?



Yes, this feature passes V8’s own mjsunit/cctest tests as well as all the
Test262 tests.


Tracking bug

v8:5368 



Link to entry on the Chrome Platform Status dashboard

https://www.chromestatus.com/feature/6035156464828416



Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no sign off from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [v8-dev] Intent to Ship: RegExp @@matchAll / String.prototype.matchAll

[Sathya Gunasekaran]

LGTM
On Thu, Dec 13, 2018 at 2:01 PM Peter Wong  wrote:
>
> Contact emails
> peter.wm.w...@gmail.com
> jgru...@chromium.org
> yang...@chromium.org
>
> math...@chromium.org
>
>
> Spec
> https://github.com/tc39/proposal-string-matchall/
>
> https://tc39.github.io/proposal-string-matchall/
>
>
> Summary
> String.prototype.matchAll behaves similarly to String.prototype.match, but 
> returns a full regexp result object for each match in a global or sticky 
> regexp.
>
> Motivation
> This offers a simple way to iterate over matches when access to e.g. capture 
> groups is needed.
>
> const string = 'Magic hex numbers: DEADBEEF CAFE 8BADF00D';
> const regex = /\b[0-9a-fA-F]+\b/g;
> for (const match of string.matchAll(regex)) {
>  console.log(match);
> }
>
> // Iteration 1:
> [
>  'DEADBEEF',
>  index: 19,
>  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
> ]
>
> // Iteration 2:
> [
>  'CAFE',
>  index: 28,
>  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
> ]
>
> // Iteration 3:
> [
>  '8BADF00D',
>  index: 33,
>  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
> ]
>
>
> Interoperability risk
> Firefox: In development - https://bugzilla.mozilla.org/show_bug.cgi?id=1435829
> Edge: No public signals
> Safari: No public signals - https://bugs.webkit.org/show_bug.cgi?id=186694
> Web developers: Positive
>
> Compatibility risk
> The spec has undergone a few updates and depending on whether other 
> implementations have kept up, there is a possibility V8 could differ in 
> behavior.  At the time of writing, V8 is current with all the latest spec 
> updates and have contributed updates to the test262 test suite to minimize 
> difference between other implementations.
>
>
> V8 tests (mjsunit) as well as all test262 tests pass for this feature.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux,
> Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/features/5520028858318848
>
> 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-...@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.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to ship: Intl.ListFormat

[Sathya Gunasekaran]

LGTM

On Thu, Nov 8, 2018 at 12:20 AM Frank Tang  wrote:

> Spec
>
> https://tc39.github.io/proposal-intl-list-format
>
> Summary
>
> A Stage 3 proposal that introduces a new formatter under Intl.
>
> Intl.ListFormat  helps libraries and frameworks format a list in a
> localized fashion by providing internationalized messages using a customary
> local word or phrase when available. For example, calling its format()
> method with ["Alice", "Bob", "Charlie", "Delta"] would return the string
> "Alice, Bob, Charlie and Delta" in English.
> Example
>
> let lf = new ListFormat("en");
>
> lf.format(["Alice"]);
>
> // > "Alicce"
>
> lf.format(["Alice", "Bob"]);
>
> // > "Alice and Bob"
>
> lf.format(["Alice", "Bob", "Charlie"]);
>
> // > "Alice, Bob and Charlie"
>
> lf.format(["Alice", "Bob", "Charlie", "Delta"]);
>
> // > "Alice, Bob, Charlie and Delta"
>
> lf = new ListFormat("zh");
>
> lf.format(["譚永鋒"]);
>
> // > "譚永鋒"
>
> lf.format(["譚永鋒", "劉新宇"]);
>
> // > "譚永鋒和劉新宇"
>
> Interoperability and compatibility risk
>
> The Intl.ListFormat is new and should have no risk to break pre-existing
> javascript code.
>
>-
>
>Firefox:In development
>-
>
>Edge:No public signals
>-
>
>Safari:No public signals
>-
>
>Web Developers: No public signals
>
>
> Is this feature fully tested?
>
> Yes; our implementation passes our own V8 tests as well as the Test262
> tests for all the features.
>
> Tracking bug
>
> https://crbug.com/v8/7871
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/features/4764538272481280
>
> 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-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship: Public class fields

[Sathya Gunasekaran]

On Wed, Oct 17, 2018 at 10:51 AM PhistucK  wrote:
>
> Are the specification and implementation compatible with the Babel based 
> implementation/interpretation of the feature? After all, previously 
> transpiled code could now be interpreted natively...
> Unfortunately, this is also considered "Web compatibility".
>

I filed several issues against Babel:
https://github.com/babel/babel/issues/6764
https://github.com/babel/babel/issues/6732
https://github.com/babel/babel/issues/6493
https://github.com/babel/babel/issues/6243
https://github.com/babel/babel/issues/6240
https://github.com/babel/babel/issues/6872

They mostly seem to be fixed which makes me optimistic that Babel is
spec compliant. If you find issues, please file bugs against Babel.

Thanks,
--Sathya

> ☆PhistucK
>
>
> On Wed, Oct 17, 2018 at 10:47 AM Sathya Gunasekaran  
> wrote:
>>
>> Contact Emails:
>> gsat...@chromium.org
>>
>> Spec:
>> https://github.com/tc39/proposal-class-fields
>> https://tc39.github.io/proposal-static-class-features/
>>
>> The linked proposal includes private fields, but this intent to ship
>> is only for public instance and static fields, not private fields.
>>
>> Summary:
>> Public class fields build upon the class syntax introduced in ES2015
>> by allowing declaration of both instance and static public fields.
>>
>> The following ES2015 syntax:
>>
>> class IncreasingCounter {
>>   constructor() {
>> this._count = 0;
>>   }
>>   get value() {
>> return this._count;
>>   }
>>   increment() {
>> this._count++;
>>   }
>> }
>>
>> can now be rewritten as:
>>
>> class IncreasingCounter {
>>   _count = 0;
>>
>>   get value() {
>> return this._count;
>>   }
>>   increment() {
>> this._count++;
>>   }
>> }
>>
>> Interoperability and compatibility risk:
>> This syntax was previously a Syntax error, therefore there is very low
>> web compat risk.
>>
>> There's one very minor spec non compliance in the current
>> implementation around the class name during static field
>> initialization (https://github.com/tc39/proposal-class-fields/issues/85)
>> which needs to be discussed at the next TC39 meeting.
>>
>> Firefox: In development  
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1499448)
>> Safari: In development (https://bugs.webkit.org/show_bug.cgi?id=174212)
>> Edge: No signal
>>
>> Is this feature fully tested?
>> V8 tests (mjsunit, cctest/test-parsing) as well as all test262 tests
>> pass for this feature.
>>
>> Chromestatus entry:
>> https://www.chromestatus.com/feature/6001727933251584
>>
>> 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.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7w_4-eJufKNB3gBzj2EsZUng0VD%3DmzbPmBr7q_-zn-yFw%40mail.gmail.com.
>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Public class fields

[Sathya Gunasekaran]

Contact Emails:
gsat...@chromium.org

Spec:
https://github.com/tc39/proposal-class-fields
https://tc39.github.io/proposal-static-class-features/

The linked proposal includes private fields, but this intent to ship
is only for public instance and static fields, not private fields.

Summary:
Public class fields build upon the class syntax introduced in ES2015
by allowing declaration of both instance and static public fields.

The following ES2015 syntax:

class IncreasingCounter {
  constructor() {
this._count = 0;
  }
  get value() {
return this._count;
  }
  increment() {
this._count++;
  }
}

can now be rewritten as:

class IncreasingCounter {
  _count = 0;

  get value() {
return this._count;
  }
  increment() {
this._count++;
  }
}

Interoperability and compatibility risk:
This syntax was previously a Syntax error, therefore there is very low
web compat risk.

There's one very minor spec non compliance in the current
implementation around the class name during static field
initialization (https://github.com/tc39/proposal-class-fields/issues/85)
which needs to be discussed at the next TC39 meeting.

Firefox: In development  (https://bugzilla.mozilla.org/show_bug.cgi?id=1499448)
Safari: In development (https://bugs.webkit.org/show_bug.cgi?id=174212)
Edge: No signal

Is this feature fully tested?
V8 tests (mjsunit, cctest/test-parsing) as well as all test262 tests
pass for this feature.

Chromestatus entry:
https://www.chromestatus.com/feature/6001727933251584

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-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [v8-team] [v8-status-updates] Intent to ship: module namespace exports

[Sathya Gunasekaran]

LGTM
On Mon, Oct 15, 2018 at 2:58 PM Georg Neis  wrote:
>
> Summary
> This feature extends the existing syntax for module exports by the form
>   export * as foo from "bar"
> which is the analogue to the existing form
>   import * as foo from "bar"
> It is equivalent to
>   import * as _foo from "bar"; export {_foo as foo}
> except that it does not introduce a local name (here _foo).
>
> Specification
> https://github.com/tc39/ecma262/pull/1174
>
> Contact
> n...@chromium.org
>
> Chrome status entry
> https://www.chromestatus.com/feature/6439734029058048
>
> V8 tracking bug
> https://bugs.chromium.org/p/v8/issues/detail?id=8101
>
> Interoperability and compatibility risk
> No risks as this is new syntax that results in a syntax error when not 
> supported.
>
> Is this feature fully tested?
> Yes, by own (V8) tests as well as Test262 tests.
>
> 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.
>
> --
> Georg Neis
> Software Engineer
>
> Google Germany GmbH
> Erika-Mann-Straße 33
> 80636 München
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>
> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten 
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen 
> Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die 
> E-Mail an die falsche Person gesendet wurde.
>
> This e-mail is confidential. If you received this communication by mistake, 
> please don't forward it to anyone else, please erase all copies and 
> attachments, and please let me know that it has gone to the wrong person.
>
> --
> You received this message because you are subscribed to the Google Groups "V8 
> status emails and design docs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to v8-status-updates+unsubscr...@google.com.
> To post to this group, send email to v8-status-upda...@google.com.
> To view this discussion on the web visit 
> https://groups.google.com/a/google.com/d/msgid/v8-status-updates/CABT__oFbT23Qh0g9idTfox5_bHr1gDUepYW134yv9iTS4RUubw%40mail.gmail.com.
>
> --
> v8-team mailing list
> v8-t...@google.com
> https://groups.google.com/a/google.com/group/v8-team

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: well-formed JSON.stringify

[Sathya Gunasekaran]

LGTM2

On Wed, Oct 3, 2018 at 2:42 PM Adam Klein  wrote:

> LGTM
>
> On Wed, Oct 3, 2018 at 8:09 AM 'Mathias Bynens' via v8-users <
> v8-users@googlegroups.com> wrote:
>
>> Contact emails
>>
>> math...@chromium.org
>>
>> Spec
>>
>> https://github.com/tc39/proposal-well-formed-stringify
>>
>> Summary
>>
>> A Stage 3 proposal changes JSON.stringify to prevent it from returning
>> ill-formed Unicode strings.
>>
>> Motivation
>>
>> RFC 8259 section 8.1 
>> requires JSON text exchanged outside the scope of a closed ecosystem to be
>> encoded using UTF-8, but JSON.stringify
>>  can return strings
>> including code points that have no representation in UTF-8 (specifically,
>> surrogate code points U+D800 through U+DFFF). And contrary to the
>> description of JSON.stringify
>> , such strings are
>> not “in UTF-16” because “isolated UTF-16 code units in the range
>> D800₁₆..DFFF₁₆ are ill-formed” per The Unicode Standard, Version 10.0.0,
>> Section 3.4 
>> at definition D91 and excluded from being “in UTF-16” per definition D89.
>>
>> However, returning such invalid Unicode strings is unnecessary, because
>> JSON strings can include Unicode escape sequences.
>>
>> Interoperability and compatibility risk
>>
>> This change is backwards-compatible, under an assumption of consumer
>> compliance with the JSON specification. User-visible effects are limited to
>> the replacement of some rare single UTF-16 code units in JSON.stringify
>> output with equivalent six-character escape sequences that can be
>> represented both in UTF-16 and in UTF-8. Any consumer accepting the current
>> ill-formed output is unaffected by this change (this is true in particular
>> of ECMAScript JSON.parse). Any consumer rejecting the current ill-formed
>> output will have a new opportunity to accept its well-formed
>> representation, although such consumers may still reject input that
>> specifies strings including Unicode code points that are not scalar values
>> (e.g. because they only accept I-JSON
>>  input), but those that accept it
>> must have mechanisms for dealing with unpaired surrogates (as mentioned in
>> the specification of JSON).
>>
>> This feature has a ready-to-land Firefox/SpiderMonkey implementation
>> . There are
>> tracking bugs for Edge/Chakra
>>  and
>> Safari/JavaScriptCore .
>>
>> Is this feature fully tested?
>>
>> Yes. In addition to V8’s own tests (
>> v8/test/mjsunit/harmony/well-formed-json-stringify*.js and
>> v8/test/cctest/test-strings*), Test262 includes tests
>> 
>> for this feature .
>>
>>
Note: Mathias rolled the latest test262 tests in to V8 (
https://chromium-review.googlesource.com/c/v8/v8/+/1259865) and V8 passes
the test262 tests for this feature.


> Tracking bug
>>
>> https://bugs.chromium.org/p/v8/issues/detail?id=7782
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/feature/5752304045129728
>>
>> 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-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to ship: Optimize await and AsyncFromSyncIterator

[Sathya Gunasekaran]

On Fri, Sep 28, 2018 at 6:39 PM Sathya Gunasekaran 
wrote:

> LGTM
>
> On Fri, Sep 28, 2018 at 7:57 AM Maya Lekova  wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Contact emailsmslek...@chromium.org
>> Explainerhttps://docs.google.com/document/d/1kL08cz4lR6gO5b2FATNK3QAfS8t-6K6kdk88U-n8tug/edit?usp=sharing
>> <https://docs.google.com/document/d/1kL08cz4lR6gO5b2FATNK3QAfS8t-6K6kdk88U-n8tug/edit?usp=sharing>SpecThe
>> ECMAScript specification change reached consensus. Pull request:
>> https://github.com/tc39/ecma262/pull/1250
>> <https://github.com/tc39/ecma262/pull/1250>The tag review process is not
>> needed, TC39 consensus was reached instead.SummaryThe goal of this change
>> is to reduce the native “await” functionality to only take 1 tick on the
>> microtask queue instead of 3.Is this feature supported on all six Blink
>> platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>> WebView)?Yes.RisksInteroperability and CompatibilityEdge: ShippedFirefox:
>> No signalsSafari: No signalsWeb developers: Shouldn’t affect web
>> developers, as most of them transpile away async/await and Babel already
>> ships with the new behaviour.*
>>
>
Note: There's a web compat risk as this changes the observable order in
which promises created by async functions are resolved. Chrome plans to
ship this with a kill switch in case we hear about breakages in the wild.

We've decided not to add a use counter for this as it will lead to
unacceptable performance regressions.


>
>>
>> *ActivationThe new behaviour won’t affect the way async/await is being
>> used.Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?Test262
>> tests are being implemented. We have related tests in the V8 repository in
>> test/inspector/debugger.Entry on the feature dashboard
>> <http://www.chromestatus.com/>Fits under
>> https://www.chromestatus.com/feature/5643236399906816
>> <https://www.chromestatus.com/feature/5643236399906816>, as this is simply
>> an errata to the spec.*
>> ---
>> Best regards,
>> Maya
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFszerUqYez-STtMj1kEkjP1M%2BGm%2Bd07E7RNcY3%3DXn9rwZ57yQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFszerUqYez-STtMj1kEkjP1M%2BGm%2Bd07E7RNcY3%3DXn9rwZ57yQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to ship: Optimize await and AsyncFromSyncIterator

[Sathya Gunasekaran]

LGTM

On Fri, Sep 28, 2018 at 7:57 AM Maya Lekova  wrote:

>
>
>
>
>
>
>
>
>
>
> *Contact emailsmslek...@chromium.org
> Explainerhttps://docs.google.com/document/d/1kL08cz4lR6gO5b2FATNK3QAfS8t-6K6kdk88U-n8tug/edit?usp=sharing
> SpecThe
> ECMAScript specification change reached consensus. Pull request:
> https://github.com/tc39/ecma262/pull/1250
> The tag review process is not
> needed, TC39 consensus was reached instead.SummaryThe goal of this change
> is to reduce the native “await” functionality to only take 1 tick on the
> microtask queue instead of 3.Is this feature supported on all six Blink
> platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
> WebView)?Yes.RisksInteroperability and CompatibilityEdge: ShippedFirefox:
> No signalsSafari: No signalsWeb developers: Shouldn’t affect web
> developers, as most of them transpile away async/await and Babel already
> ships with the new behaviour.ActivationThe new behaviour won’t affect the
> way async/await is being used.Is this feature fully tested by
> web-platform-tests
> ?Test262
> tests are being implemented. We have related tests in the V8 repository in
> test/inspector/debugger.Entry on the feature dashboard
> Fits under
> https://www.chromestatus.com/feature/5643236399906816
> , as this is simply
> an errata to the spec.*
> ---
> Best regards,
> Maya
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFszerUqYez-STtMj1kEkjP1M%2BGm%2Bd07E7RNcY3%3DXn9rwZ57yQ%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to ship: Intl.RelativeTimeFormat

[Sathya Gunasekaran]

LGTM

On Mon, Sep 24, 2018 at 5:35 PM Frank Tang  wrote:

> Spec
>
> https://tc39.github.io/proposal-intl-relative-time/
>
> Summary
>
> A Stage 3 proposal that introduces a new formatter under Intl.
>
> Intl.RelativeTimeFormat is a low level API to facilitate libraries and
> frameworks to format relative time in a localized fashion by providing
> internationalized messages for date and time fields, using customary word
> or phrase when available.
> Example
>
> let rtf = new Intl.RelativeTimeFormat("en");
> // Format relative time using the day unit.rtf.format(-1, "day");// > 
> "yesterday"
> rtf.format(2.15, "day");// > "in 2.15 days"
> rtf.format(100, "day");// > "in 100 days"
> rtf.format(0, "day");// > "today"
> rtf.format(-0, "day");// > "today"
>
> // Format relative time using the day unit.rtf.formatToParts(-1, "day");// > 
> [{ type: "literal", value: "yesterday"}]
> rtf.formatToParts(100, "day");// > [{ type: "literal", value: "in " }, { 
> type: "integer", value: "100", unit: "day" }, { type: "literal", value: " 
> days" }]
>
> Interoperability and compatibility risk
>
> The Intl.RelativeTimeFormat is new and should have no risk to break
> pre-existing javascript code.
>
>- Firefox:In development
>- Edge:No public signals
>- Safari:No public signals
>- Web Developers:Positive
>
>
> Is this feature fully tested?
>
> Yes; our implementation passes our own V8 tests as well as the Test262
> tests for all the features.
>
> Tracking bug
>
> https://crbug.com/v8/7869
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/feature/4875177569550336
>
> 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-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: globalThis

[Sathya Gunasekaran]

LGTM

On Thu, Aug 30, 2018 at 8:23 AM Adam Klein  wrote:

> This LGTM, based on the stage at TC39.
>
> It'd be nice if we knew more about other browser plans, given the history
> here. Do you know if Firefox has plans to try again with this name anytime
> soon?
>
> On Thu, Aug 30, 2018 at 1:24 AM 'Mathias Bynens' via v8-users <
> v8-users@googlegroups.com> wrote:
>
>> Contact emails
>>
>> math...@chromium.org
>>
>> Spec
>>
>> https://tc39.github.io/proposal-global/
>>
>> Summary
>>
>> A Stage 3 proposal introduces globalThis, enabling a universal mechanism
>> to access the global object even in strict functions or modules, regardless
>> of the platform.
>>
>> Motivation
>>
>> It is difficult to write portable ECMAScript code which accesses the
>> global object. On the web, it is accessible as window or self or this or
>> frames; on Node.js, it is global or this; among those, only this is
>> available in a shell like V8's d8. In a standalone function call in
>> sloppy mode, this works too, but it's undefined in modules or in strict
>> mode within a function. In such contexts, the global object can still be
>> accessed using Function('return this')(), but that form is incompatible
>> with some CSP settings, such as within Chrome Apps.
>>
>> Interoperability and compatibility risk
>>
>> An earlier version of this proposal had a different name: global. Sadly,
>> this name was found to be not Web-compatible when Firefox shipped it
>> . After collaborating
>> with other browsers vendors and looking at data on real-world use of
>> JavaScript identifiers on the web, we believe the new name to be
>> Web-compatible.
>>
>> Is this feature fully tested?
>>
>> Yes. In addition to V8's own tests (v8/test/mjsunit/harmony/global*.js),
>> Test262 includes tests for this feature
>> 
>> .
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/v8/issues/detail?id=5537
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/feature/6571514765770752
>>
>> 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-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] chrome://flags/#enable-array-prototype-values, have been removed with version 68.0.3440.75 so we can not set "Array.prototype.values ES6 method" to ‘Disabled’ and that is causing us iss

['Sathya Gunasekaran' via v8-users]

This flag was just for debugging purposes. There's no way to add it
back. If this is for Microsoft CRM 2011, you'll have to update to a
more latest version of the CRM software. Microsoft has informed us
that they will not update this as mainstream support for CRM 2011 has
been terminated for over two years now. CRM 2011 does not work on any
of the latest browsers.
On Tue, Jul 31, 2018 at 3:31 PM  wrote:
>
> chrome://flags/#enable-array-prototype-values, have been removed with version 
> 68.0.3440.75 so we can not set "Array.prototype.values ES6 method" to 
> ‘Disabled’ anymore and that is causing us issue with CRM.  How can we put 
> this back ?
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups 
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: Symbol.prototype.description

[Sathya Gunasekaran]

LGTM

Note: This proposal is at Stage 3 (which signals that this is ready
for shipping).
On Fri, Jun 8, 2018 at 8:57 AM Joyee Cheung  wrote:
>
> Contact emails
>
> jo...@igalia.com, gsat...@chromium.org
>
> Spec
>
> https://tc39.github.io/proposal-Symbol-description/
>
> Summary
>
> This proposal Expose the [[Description]] internal slot of a symbol directly 
> instead of just indirectly through Symbol.prototype.toString.
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, 
> Chrome OS, Android, and Android WebView)?
>
> Yes.
>
> Interoperability risk
>
> Edge: No public signals
>
> Firefox: No public signals
>
> Safari: No public signals
>
> Tests
>
> test262 contains tests for Symbol.prototype.description, which V8 passes.
>
> V8 also has its own tests: 
> https://chromium.googlesource.com/v8/v8/+/master/test/mjsunit/harmony/symbol-description.js
>
> Tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=7807
>
> Entry on the feature dashboard
>
> https://www.chromestatus.com/features/5340787290144768
>
> 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-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups 
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to ship: Array.prototype.{flat,flatMap}

[Sathya Gunasekaran]

LGTM
On Wed, May 23, 2018 at 11:26 AM Mathias Bynens 
wrote:

> Contact emails

> math...@chromium.org, bmeu...@chromium.org


> Spec

> https://tc39.github.io/proposal-flatMap/


> Summary

> A Stage 3 proposal introduces two new array methods.

> Array.prototype.flat flattens arrays recursively up to the specified
depth, which defaults to 1.

> // Flatten one level:
> const array = [1, [2, [3]]];
> array.flat();
> // → [1, 2, [3]]

> // Flatten recursively until the array contains no more nested arrays:
> array.flat(Infinity);
> // → [1, 2, 3]

> The same proposal includes Array.prototype.flatMap, which is like
Array.prototype.map except it flattens the result into a new array.

> [2, 3, 4].flatMap((x) => [x, x * 2]);

> // → [2, 4, 3, 6, 4, 8]

> Interoperability and compatibility risk

> The flat method was originally called flatten, which was found to be not
Web-compatible when Firefox shipped it. More recently, flatten was renamed
into flat in the hopes of it resolving the compatibility issue.


> Firefox: Public support (they shipped the proposal in its earlier form,
and will now rename)

> Edge: No public signals

> Safari: Public support (Safari TP currently has a flatten implementation
which they’ll rename)

> Web developers: Strongly positive


> Is this feature fully tested?

> Yes; our implementation passes our own V8 tests as well as the Test262
tests for these two features.


> Tracking bug

> https://bugs.chromium.org/p/v8/issues/detail?id=7220


> Link to entry on the Chrome Platform Status dashboard

> https://www.chromestatus.com/feature/6629507075145728


> 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.


> --
> You received this message because you are subscribed to the Google Groups
"blink-dev" group.
> To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRga6aY7zgR6x-8YuXCBYZGurPSzR9F4_%3DqK%2B7D_ADGY4-Q%40mail.gmail.com
.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Numeric separators

[Sathya Gunasekaran]

Note that this is a v8/JavaScript feature, so this post is just an FYI for
blink-dev — no sign-off from Blink API owners is required.

Contact Emails:
gsat...@chromium.org
b...@b6n.ch

Spec:
https://tc39.github.io/proposal-numeric-separator/

Summary:
This feature enables developers to make their numeric literals more
readable by creating a visual separation between groups of digits. Using
underscores (_, U+005F) as separators helps improve readability for numeric
literals, for ex: 1_000_000_000.

Interoperability and Compatibility Risk:
This is a Stage3 feature in the TC39 process. Previously this was a
SyntaxError so there is no compat risk.

Safari and Edge have not implemented this feature. This is under
development in Firefox.

V8 tests as well as test262 tests pass.

Tracking bug:
https://bugs.chromium.org/p/v8/issues/detail?id=7317

Chromestatus entry:
https://www.chromestatus.com/feature/5829906369871872

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [v8-dev] Intent to ship: BigInt, BigInt64Array, BigUint64Array

[Sathya Gunasekaran]

LGTM

On Fri, Mar 2, 2018 at 11:25 AM, Jakob Kummerow  wrote:
> Note that this is a v8/JavaScript feature, so this post is just an FYI for
> blink-dev — no signoff from Blink API owners is required.
>
>
> Contact emails
>
> jkumme...@chromium.org, n...@chromium.org
>
>
> Explainer
>
> https://github.com/tc39/proposal-bigint/blob/master/README.md
>
>
> Spec
>
> https://tc39.github.io/proposal-bigint
>
>
> Summary
>
> This proposal brings arbitrary-precision integers to JavaScript, along with
> new TypedArrays with signed and unsigned 64-bit integer elements.
>
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> Yes.
>
>
> Debuggability
>
> As of this writing, DevTools support is being worked on. It will be
> available before shipping.
>
> All the usual DevTools features will work for code containing BigInts.
>
>
> Interoperability risk
>
> Edge: No public signals
>
> Firefox: In development:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1366287
>
> Safari: In development: https://bugs.webkit.org/show_bug.cgi?id=179001
>
> Web developers: Positive, e.g.
> https://github.com/tc39/proposal-bigint/issues/53
>
>
> Compatibility risk
>
> BigInt literals were invalid syntax before.
>
> The "BigInt", "BigInt64Array", "BigUint64Array" constructors could clash
> with user-defined globals.
>
>
> Activation risk
>
> The semantics of the BigInt proposal are not polyfillable (it would require
> operator overloading).
>
>
> Tests
>
> test262 contains tests for BigInt, BigInt64Array, BigUintArray, which V8
> passes.
>
> V8 also has its own tests:
> https://chromium.googlesource.com/v8/v8/+/master/test/mjsunit/harmony/bigint
>
>
> Tracking bug
>
> crbug.com/v8/6791
>
>
> Entry on the feature dashboard
>
> https://www.chromestatus.com/features/5371603852460032
>
>
> Requesting approval to ship?
>
> Yes.
>
> We would like to ship BigInts on ToT in ~3 weeks, in time for Chrome 67.
>
>
> --
> --
> v8-dev mailing list
> v8-...@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.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Double Proxy resolve/reject causes segfault

[Sathya Gunasekaran]

Thanks for the report. Fix out for review: https://chromium-
review.googlesource.com/c/v8/v8/+/932968

On Thu, Feb 22, 2018 at 12:17 PM, Bogdan Padalko 
wrote:

> Hi!
>
> While working on upgrading php-v8 extension from 6.5.144 to 6.6.275 I
> find a strange issue: when promise in non-pending stage get
> resolved/rejected, application fails with segfault. While it's an edge
> case, it still possible in userland and luckily it was covered by php-v8
> unit tests.
> As v8 API says that calling resolve/reject on a promise in non-pending
> state should have no effect, I find this segfault a bit strange. Could it
> be some regression or so?
>
> Here's minimal example to reproduce the issue: hello_world.cpp
>
> #include 
> #include 
>
> #include 
> #include 
>
> using namespace v8;
>
> int main(int argc, char* argv[]) {
>   // Initialize V8.
>   //v8::V8::InitializeICU();
>
>   std::unique_ptr platform = v8::platform::NewDefaultPlatfo
> rm();
>   v8::V8::InitializePlatform(platform.get());
>
>   V8::Initialize();
>
>   v8::Isolate::CreateParams create_params;
>   create_params.array_buffer_allocator = v8::ArrayBuffer::Allocator::Ne
> wDefaultAllocator();
>
>   // Create a new Isolate and make it the current one.
>   Isolate* isolate = v8::Isolate::New(create_params);
>
>   v8::Persistent test;
>
>   {
> Isolate::Scope isolate_scope(isolate);
>
> // Create a stack-allocated handle scope.
> HandleScope handle_scope(isolate);
>
> // Create a new context.
> Local context = Context::New(isolate);
>
> // Enter the context for compiling and running the hello world script.
> Context::Scope context_scope(context);
>
> Local local_value = String::NewFromUtf8(isolate, "test");
>
> v8::MaybeLocal maybe_local_resolver = v8::
> Promise::Resolver::New(context);
> v8::Local local_resolver = maybe_local_resolver
> .ToLocalChecked();
>
> local_resolver->Resolve(context, local_value);
> local_resolver->Resolve(context, local_value);
>   }
>
>   // Dispose the isolate and tear down V8.
>   isolate->Dispose();
>   V8::Dispose();
>   V8::ShutdownPlatform();
>
>   return 0;
> }
>
> Build on macOS with
>
> ROOT=/usr/local/opt/v8@6.6
> LIB_DIR=$ROOT/lib/
>
> SRC_DIR=$ROOT
> INCLUDE_DIR=$ROOT/include
>
> g++ hello_world.cpp -o hello_world \
>  -Wno-unused-result \
>  -g \
>  -O2 \
>  -std=c++14 \
>  -I$SRC_DIR \
>  -I$INCLUDE_DIR \
>  -L$LIB_DIR \
>  -lv8_libbase \
>  -lv8_libplatform \
>  -lv8 \
>  -lpthread
>
> install_name_tool -add_rpath $LIB_DIR hello_world
>
> And fails with
> $ ./hello_world
> Received signal 11 SEGV_MAPERR 000a
>
>  C stack trace ===
>
>  [0x000106d8ff14]
>  [0x7fff6ca6bf5a]
>  [0x0001072d0984]
>  [0x000106de95e8]
>  [0x000106d79bb2]
>  [0x7fff6c7ea115]
>  [0x0001]
> [end of stack trace]
> Segmentation fault: 11
>
> Same issue on linux - https://travis-ci.org/pinepain/php-v8/jobs/344550482
> (scroll to the bottom).
>
> I would really appreciate any help here as I'm not quite sure whether it's
> an issue on my side or some regression/bug in v8.
>
> Regards,
> Bogdan
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: [blink-dev] Intent to ship: JSON ⊂ ECMAScript

[Sathya Gunasekaran]

LGTM

On Fri, Feb 16, 2018 at 5:24 AM, PhistucK  wrote:
> I know.
>
> Regarding "public support" - not "opposed" does not necessarily mean
> "support" (it could be neutral). Transparency is important in
> chromestatus.com (and in intent, I would argue).
> Second, web developers are not part of the TC39 stages, so support or
> reactions from them are not a given (not as far as "strongly positive").
> I think it makes sense to add links for opinions that are not your own.
>
> Just my two or three cents.
>
>
> ☆PhistucK
>
> On Fri, Feb 16, 2018 at 3:07 PM, Mathias Bynens  wrote:
>>
>> 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.
>>
>> For ECMAScript features like this one, if a browser vendor would be
>> opposed to this proposal, they would block its advancement at TC39. Given
>> that this proposal already made it to Stage 3 I would be surprised if
>> vendors would suddenly change their mind now.
>>
>> On Fri, Feb 16, 2018 at 1:50 PM, PhistucK  wrote:
>>>
>>> (At least on blink-dev)
>>> "Interoperability risk" should have links for citing each vendor and web
>>> developer support.
>>>
>>>
>>> ☆PhistucK
>>>
>>> On Fri, Feb 16, 2018 at 2:15 PM, Mathias Bynens 
>>> wrote:

 Contact emails

 math...@chromium.org


 Spec

 https://github.com/tc39/proposal-json-superset


 Summary

 A Stage 3 proposal makes ECMAScript a syntactic superset of JSON by
 allowing U+2028 and U+2029 in string literals.


 Motivation

 ECMAScript claims JSON as a subset in JSON.parse, but (as has been
 well-documented) that is not true because JSON strings can contain 
 unescaped
 U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR characters while
 ECMAScript strings cannot.

 These exceptions add unnecessary complexity to the specification and
 increase the cognitive burden on both implementers and users, allowing for
 the introduction of subtle bugs. Also, as a lesser but concrete corollary
 problem, certain source concatenation and construction tasks currently
 require additional steps to process valid JSON into valid ECMAScript before
 embedding it.


 Interoperability risk

 Firefox: Public support

 Edge: Public support

 Safari: Public support

 Web developers: Strongly positive


 Compatibility risk

 This change is backwards-compatible. User-visible effects will be
 limited to the elimination of SyntaxError completions when parsing strings
 that include unescaped LINE SEPARATOR or PARAGRAPH SEPARATOR characters,
 which in practice are uncommon.


 Is this feature fully tested?

 Yes; see
 v8/test/cctest/test-parsing/LineOrParagraphSeparator{AsLineTerminator,InStringLiteral,InStringLiteralHarmony}.


 Tracking bug

 https://bugs.chromium.org/p/v8/issues/detail?id=7418


 Link to entry on the Chrome Platform Status dashboard

 https://www.chromestatus.com/features/6102319234023424


 Requesting approval to ship?

 Yes

 --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+unsubscr...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJYpFjDOzdTHBNJR0oheBPOtKCETJQUxPqd3pYCz3DA8%3DGKRTg%40mail.gmail.com.
>>>
>>>
>>
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: String.prototype.trimStart / String.prototype.trimEnd

[Sathya Gunasekaran]

LGTM

On Fri, Feb 9, 2018 at 8:36 AM, Benedikt Meurer 
wrote:

> LGTM
>
>
> Mathias Bynens  schrieb am Fr., 9. Feb. 2018, 16:36:
>
>> Contact emails math...@chromium.org Spec https://github.com/tc39/
>> proposal-string-left-right-trim Summary Until now,
>> String.prototype.{trimLeft,trimRight} were non-standard language
>> extensions, required for Web compatibility. The Stage 3 proposal at
>> https://github.com/tc39/proposal-string-left-right-trim standardizes
>> this functionality as String.prototype.{trimStart,trimEnd}, and defines
>> String.prototype.{trimLeft,trimRight} as aliases for backwards
>> compatibility. Vendor signals Firefox: Public support Edge: Public
>> support Safari: In development Web developers: Positive Compatibility
>> risk
>> There could be a compatibility risk, but that seems unlikely. We won’t
>> know for sure until we try shipping it. Ongoing technical constraints
>> None Will this feature be supported on all six Blink platforms (Windows,
>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>> Yes
>> Tracking bug
>> https://bugs.chromium.org/p/v8/issues/detail?id=6530 Link to entry on
>> the Chrome Platform Status https://www.chromestatus.com/
>> features/479006651936 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-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
>
>
> * •  *
> *Benedikt Meurer** •  **Google Germany GmbH*
> * •  *Erika-Mann-Str. 33
> 
> * •
> *80636
> Munich
> 
>
>  •  bmeu...@google.com
>
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>
> Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft:
> Hamburg
>
> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
> leiten Sie diese bitte nicht weiter, informieren Sie den Absender und
> löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is
> confidential. If you are not the right addressee please do not forward it,
> please inform the sender, and please erase this e-mail including any
> attachments. Thanks.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Array.prototype.values

[Sathya Gunasekaran]

Contact Emails:
gsat...@chromium.org

Spec:
https://tc39.github.io/ecma262/#sec-array.prototype.values

Summary:
The values() method returns a new Array Iterator object that contains the
values for each index in the array.

Compatibility Risk:
The compat risk is high. There has been two attempts to ship this already
back in 2014 and 2016, both of which found this to be web incompatible. For
more details see:
https://bugs.chromium.org/p/chromium/issues/detail?id=409858
https://bugs.chromium.org/p/chromium/issues/detail?id=615873

Both the launches were found to be incompatible with enterprise software
(that couldn't be easily updated). Unfortunately, there's no easy to way to
find out if this is still the case today.

The shipping plan is to enable this feature by default and add both: a
finch and an about:flags kill switch.

The finch kill switch can be used to turn this off if more than just the
enterprise site breaks. The about:flags kill switch can be toggled by the
enterprise site users if it breaks, leaving the rest of the world to enjoy
Array.prototype.values.

Interoperability:
Edge and Safari both ship this feature.

Firefox does not ship this. They had similar web compat problems when they
tried to ship this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1299444

But they plan to try and ship this again soon along with Chrome:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420101

Tracking bug:
https://bugs.chromium.org/p/v8/issues/detail?id=4247

Chromestatus entry:
https://www.chromestatus.com/feature/4755812090118144

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Optional catch binding

[Sathya Gunasekaran]

Contact Emails:
gsat...@chromium.org
bak...@gmail.com

Spec:
https://tc39.github.io/proposal-optional-catch-binding/

Summary:
This proposal allows developers to use try/catch without creating an unused
binding.

Interoperability and Compatibility Risk:
This is a stage3 feature. Previously not having a binding was an error, so
there's no compat risk.

Firefox 58 Beta and Safari Tech Preview 37 ship this feature. Edge has not
implemented this yet.

V8 tests as well as test262 tests pass.

Tracking bug:
https://bugs.chromium.org/p/v8/issues/detail?id=6889

Chromestatus entry:
https://www.chromestatus.com/features/5810795665424384

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: [blink-dev] Intent to Ship: Async Iteration / Async Generators

[Sathya Gunasekaran]

LGTM2!

On Tue, Sep 12, 2017 at 1:59 PM, Adam Klein  wrote:
> LGTM!
>
> On Tue, Sep 12, 2017 at 9:48 AM, Caitlin Potter  wrote:
>>
>> Contact Emails
>>
>> ca...@chromium.org
>>
>> Spec
>>
>> https://tc39.github.io/proposal-async-iteration/
>>
>> Summary
>>
>> Async Generators and the new Async Iteration protocol provide tools for
>> implementing and consuming data sources not synchronously available in
>> their
>> entirety. A common use-case is to wrap ReadableStreams for consumption via
>> `for-await-of` loops (example:
>> https://jakearchibald.com/2017/async-iterators-and-generators/).
>>
>> Motivation
>>
>> Promises and Streams are a part of the platform, both from the perspective
>> of the world-wide-web,
>> and from the perspective of Node.js. This feature provides a streamlined,
>> readable interface for
>> interacting with complex platform tools, and enables developers to more
>> easily implement
>> complex schemes which cannot run synchronously.
>>
>> Interoperability risk
>>
>> * Firefox: In development
>> * Edge: Public support
>> * Safari: In development
>> * Web developers: No signals
>>
>> Compatibility risk
>>
>> Low compatibility risk. There is some risk due to Babel's shipment of an
>> incorrect implementation of
>> the standard, and the complexity of feature-testing. That said, the
>> feature has been staged for several
>> weeks now, and content creators most at risk of running into compatibility
>> risks would have likely
>> encountered them by now during this period.
>>
>> Ongoing technical constraints
>>
>> None (granted, more work is likely needed to reduce the overhead of the
>> feature on low-end devices)
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes
>>
>> OWP launch tracking bug
>>
>> https://bugs.chromium.org/p/v8/issues/detail?id=5855
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://www.chromestatus.com/feature/5727385018171392
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7DFC3057-2841-4B25-9568-FB896C162F20%40chromium.org.
>
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Promise.prototype.finally

[Sathya Gunasekaran]

Contact Emails:
gsat...@chromium.org

Spec:
https://tc39.github.io/proposal-promise-finally/

Summary:
This finally method is used for registering a callback to be invoked
when a promise is settled (either fulfilled, or rejected).

Interoperability and Compatibility Risk:
This is a stage3 feature. This adds a fairly minimal method on
Promise.prototype.

Webkit has shipped this in Safari Tech Preview Release 37.
This feature is under development in Firefox.
Edge has not implemented this yet.

V8 tests as well as test262 tests pass.

Tracking bug:
https://bugs.chromium.org/p/v8/issues/detail?id=5967

Chromestatus entry:
https://www.chromestatus.com/feature/5704570235781120

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: Intent to Implement: JavaScript module import()

[Sathya Gunasekaran]

On Wed, Jul 5, 2017 at 7:56 PM, Zac Hansen  wrote:
> Is this related, in any way, to
> https://v8.paulfryzel.com/docs/master/classv8_1_1_module.html ?
>
> Will this documentation be updated as a part of this implementation, if
> appropriate?
>

The relevant documentation is here:
https://cs.chromium.org/chromium/src/v8/include/v8.h?l=6120=b520c6ed5eadf29b950a0fc567a327b93c48c02d

The tracking bug for V8
(https://bugs.chromium.org/p/v8/issues/detail?id=5785) has more
information (including a design doc).

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Implement: JavaScript module import()

[Sathya Gunasekaran]

Contact emails

V8 implementation: gsat...@chromium.org

Blink implementation: kou...@chromium.org

Spec: dome...@chromium.org

Spec

JavaScript side: https://tc39.github.io/proposal-dynamic-import/

This is a stage 3 proposal, which per the TC39 process
 is the appropriate time to
implement (and ship).

Web side:
https://github.com/tc39/proposal-dynamic-import/blob/master/HTML%20Integration.md

This is a (detailed) draft which will be integrated into HTML
 shortly.

Summary

import() is an addition to the JavaScript module system which allows
dynamic importing of modules, as opposed to the static/declarative
importing provided by the import declaration. It is a new JavaScript
"function-like" syntactic form, similar to super().

Motivation

(From
https://github.com/tc39/proposal-dynamic-import#motivation-and-use-cases)

The existing syntactic forms for importing modules are static declarations.
They accept a string literal as the module specifier, and introduce
bindings into the local scope via a pre-runtime "linking" process. This is
a great design for the 90% case, and supports important use cases such as
static analysis, bundling tools, and tree shaking.

However, it's also desirable to be able to dynamically load parts of a
JavaScript application at runtime. This could be because of factors only
known at runtime (such as the user's language), for performance reasons
(not loading code until it is likely to be used), or for robustness reasons
(surviving failure to load a non-critical module). Such dynamic
code-loading has a long history, especially on the web, but also in Node.js
(to delay startup costs). The existing `import` syntax does not support
such use cases.

Truly dynamic code loading also enables advanced scenarios, such as racing
multiple modules against each other and choosing the first to successfully
load.

---

Today this is also possible via dynamically creating and inserting 

[v8-users] Intent to Ship: Object rest/spread properties

[Sathya Gunasekaran]

Contact Emails:
gsat...@chromium.org

Spec:
https://tc39.github.io/proposal-object-rest-spread/

Summary:
ECMAScript 6 introduced rest elements for array destructuring
assignment and spread elements for array literals. This proposal
introduces analogous rest properties for object destructuring
assignment and spread properties for object literals.

Rest properties collect the remaining own enumerable property keys
that are not already picked off by the destructuring pattern. Those
keys and their values are copied onto a new object.

Spread properties in object initializers copies own enumerable
properties from a provided object onto the newly created object.

Interoperability and Compatibility Risk:
This is a stage 3 feature.

This new language feature allows syntax that was previously a
SyntaxError, so compatibility risk is low.

Webkit has shipped this in Safari Tech Preview Release 27. Firefox and
Edge have not implemented this yet.

Tracking bug:
https://bugs.chromium.org/p/v8/issues/detail?id=5549

Chrome status entry:
https://www.chromestatus.com/feature/5657004848709632

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: Trailing comma in JavaScript function parameter lists

[Sathya Gunasekaran]

LGTM

On Fri, Jan 13, 2017 at 1:55 PM, jwolfe  wrote:
> Summary:
>
> Allow a trailing comma in function parameter declarations and function call
> parameters. Example:
>
> function f(a, b,) {
>   return a + b;
> }
> let g = (a, b,) => a + b;
> f(1, 2,) + g(3, 4,);
>
> The purpose of this feature is to better support writing each parameter on
> its own line:
>
> function f(
> longParameterName1, // documentation for parameter
> longParameterName2, // documentation for parameter
> longParameterName3, // documentation for parameter
>   ) {
> }
> f(
>   complicatedExpression(), // this is longParameterName1
>   complicatedExpression(), // this is longParameterName2
>   complicatedExpression(), // this is longParameterName3
> );
>
> Allowing the final comma is beneficial when editing the code. If you want to
> reorder the parameters, you needn't add and remove commas from some of the
> lines sometimes. If you want to add a new final parameter, you can simply
> add a line without modifying the previous line. This makes version-control
> diffs cleaner and also makes editing code less troublesome and error prone.
> Trailing commas are allowed in array and object literal syntax for the same
> reasons.
>
>
> Interoperability and Compatibility Risk:
>
> This new language feature allows syntax that was previously a SyntaxError,
> so compatibility risk is low.
>
> This feature is in the draft ES2017 spec.
>
> Firefox has implemented (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1303788 ) but not yet shipped
> this feature.
> Webkit has implemented ( https://bugs.webkit.org/show_bug.cgi?id=158020 )
> but not yet shipped this feature.
> Edge is shipping with this feature enabled (
> https://kangax.github.io/compat-table/es2016plus/ ).
>
>
> Spec:
>
> https://tc39.github.io/proposal-trailing-function-commas/
>
>
> Tracking bug:
>
> https://bugs.chromium.org/p/v8/issues/detail?id=5051
>
>
> Entry on the feature dashboard ( https://www.chromestatus.com/features ):
>
> https://www.chromestatus.com/feature/5656834660630528
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.