Re: [v8-users] V8 Regex Optimizations

['Mathias Bynens' via v8-users]

We recently posted an article detailing some recent improvements:
https://v8.dev/blog/regexp-tier-up

On Wed, Oct 23, 2019 at 5:12 PM Joel Scarfone 
wrote:

> Hi!
>
> I'm looking for details on how v8's regular expression optimizations work
> under the covers, and if there might be something to improve the
> performance of a given regular expressions first execution. From what it
> looks like trying some things out, v8 does most of it's optimizations after
> a call that uses the RegExp and not when the constructor is called (eg.
> through `new RegExp()`).
>
> I am Wondering what some options are in this area to move around the cost
> of compiling/running the regular expression.
>
> Thanks in advance!
>
> Joel
>
> --
> --
> 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/05a13931-5a1d-4b21-8616-ffd3010dd03a%40googlegroups.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/CADizRgZF3yQzmsggVtnmyPubtVyRmT%3DVAfVtHqVihHh9b6TqeQ%40mail.gmail.com.

[v8-users] Re: [blink-dev] Intent to Remove: 'getThis' and 'getFunction' from the CallSite API

['Mathias Bynens' via v8-users]

Non-Blink owner LGTM. As Simon points out, Error.prepareStackTrace is
non-standard, and so I'm in favor of removing as much from it as we can.

On Tue, Jul 2, 2019 at 6:15 PM 'Simon Zünd' via blink-dev <
blink-...@chromium.org> wrote:

> Contact emails szu...@chromium.org Summary A callback installed on the
> non-standard Error.prepareStackTrace receives a list of CallSite objects.
> These objects have various accessors on them, 'getThis' and 'getFunction'
> among them. In-depth information:
> https://v8.dev/docs/stack-trace-api#customizing-stack-traces
>
> These two functions are rarely used and complicate the stack trace
> implementation.
> 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 web-platform-tests
> 
> ? No Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5975936472186880
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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/CACswSC14TCiY%2BTA6PNPP1HEpR3tJMw24pCxG81Ta1CjL9%3DapqQ%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/CADizRgZwhXvYoKHcRh0HS_arZKBHFumKm3CWM3HQgb0S4aPAvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Implement: "numberingSystem" option for Intl.NumberFormat / "calendar" and "numberingSystem" option for Intl.DateTimeFormat

['Mathias Bynens' via v8-users]

LGTM

*From: *Frank Tang 
*Date: *Tue, May 14, 2019 at 5:33 PM
*To: *blink-dev, v8-users, , Adam Klein, Sathya
Gunasekaran, Jakob Kummerow, Nebojša Ćirić

Contact emails ft...@chromium.org,js...@chromium.org Explainer
> https://github.com/tc39/ecma402/pull/175 Design docs/spec Specification:
> https://github.com/tc39/ecma402/pull/175
> https://github.com/tc39/ecma402/pull/175 TAG review No need for TAG
> review since the TC39 / ECMA402 process provide oversight. Summary Allows
> calendar and numberingSystem to be specified in the options bag of the
> DateTimeFormat and NumberFormat constructors. Motivation One use case for
> these options would be, when working with locales which have two numbering
> systems and calendars in use--the UA default may be the non-Western one,
> but in some contexts, it may be appropriate to use the Western one.
> Currently, without the patch, it would be necessary to parse the BCP 47
> language tag in the application. This feature make it simpler for the
> developer. See https://github.com/tc39/ecma402/pull/175 for more details.
> Risks
> Interoperability and Compatibility The PR in
> https://github.com/tc39/ecma402/pull/175 is in last stage to be merged
> into ECMA402. *Firefox*: No public signals *Edge*: No public signals
> *Safari*: No public signals *Web developers*: No signals Ergonomics
> Small. Both Intl object already provide the underline format functionality
> by reading calendar ("ca") and numberingSystem ("nu") from the locale. This
> feature only add a tiny option reading step Activation Low. A lot of
> users already use these two API . New Javascript code which follow this
> change running on an old version of browser which does not support this
> browser will format the number and/or date in different result. But users
> should still be able to understand these output. Security None
> Debuggability No additional debugging support required. 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
> web-platform-tests
> 
> ? Yes Tests will be added to test262 before launching Link to entry on
> the Chrome Platform Status
> https://www.chromestatus.com/features/5440249461211136
>
> --
> --
> 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/CAOcELL_AamuY_jQBmqQjLUW7rswNNih3AQ2SxJ%2BG8CP4r%2Bn9GQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CADizRgZjxUqvVs9CP9MhknDD5Lc%3DrCwdGK33WtXsbo%2B3SiMtYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to Implement: Intl.DisplayNames API Proposal

['Mathias Bynens' via v8-users]

Can the doc at https://goo.gl/im9wy4 be made public please?

Usually we only implement features at stage 3. What’s the motivation for
implementing this particular API earlier? (Not saying I’m opposed to it.)

*From: *Frank Tang 
*Date: *Mon, May 13, 2019 at 9:43 PM
*To: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
Gunasekaran, Mathias Bynens, Nebojša Ćirić, ,
Jungshik Shin, Shane Carr

Title: Intent to Implement: Intl.DisplayNames API Proposal
>
>
>
> Contact emails
>
> ft...@chromium.com
>
>
>
> Explainer
>
> https://github.com/tc39/proposal-intl-displaynames
>
> https://tc39.github.io/proposal-intl-displaynames/
>
>
> Design doc/Spec
>
> Engineering Plan https://goo.gl/im9wy4
>
>
> Summary
>
> Provides a new API to get localized names of language, region, script,
> currency codes of international standard as well as commonly used names of
> date fields and symbols.
>
>
> Motivation
>
> Main motivation for Intl.DisplayNames project was to enable developers to
> get translation of language, region or script display names on the client.
> Translation of languages, regions or script display names requires large
> amount of data to transmit on the network, which is already available in
> most browsers. These display name translations also carry steep data size
> penalty for developers. This API will allow web developers to shrink the
> size of their HTML and/ or ECMAScript code without the need to include the
> human readable form of display names and therefore reduce the download size
> to decrease latency. Also, this API will reduce the localization cost for
> the web developers. Our goal is to expose this data through Intl API for
> use in e.g. language, region and script pickers, etc.
>
>
> Benefit
>
>-
>
>Reduce download size of apps and therefore improve latency.
>-
>
>Easy for users to build internationalized language, region or script
>selection UI components (drop down menu or other kinds).
>-
>
>Reduce translation cost for developers.
>-
>
>Consistent translation of language, region and script display name on
>the web.
>
>
> Risks
>
> Interoperability and Compatibility
>
> This is a new API. It is currently under TC39 Stage 1 and we plan to
> propose to advance it to Stage 2 in June 2019.
>
>
> Ergonomics
>
>
> Activation
>
> Web developers could use the API immediately upon our shipment.
>
>
> Debuggability
>
> Nothing special.
>
>
>
> 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 web-platform-tests
> 
> ?
>
> Tests under tc39/test262 will includes many tests to test this API.
>
>
> Link to entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/4965112605573120
>
>
> Requesting approval to ship?
>
> “No”. The feature is behind a runtime flag harmony_intl_display_names and
> I will later send an Intent to Ship
> 
> email when I am ready to enable by default.
>

-- 
-- 
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/CADizRgY2QWvOY2xzu1_1CJWGVSk1w6jcuDV790ZwixQx8vMGcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

['Mathias Bynens' via v8-users]

Non-API owner LGTM. Optimize all the things!

On Thu, Apr 25, 2019 at 8:47 PM Adam Klein  wrote:

> Non-API owner LGTM, as this is a very low-risk change. Its only expected
> impact will be a performance improvement/simplification.
>
> And a reminder to API owners to look at this, since we've just switched
> V8/JS features over to using the Blink Intent process.
>
> On Thu, Apr 25, 2019 at 11:44 AM Sathya Gunasekaran 
> wrote:
>
>> 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
>>
>> --
>> 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/CAMd%2BM7wqinO2%3DbAMH%2BhyKzAEQowJXodfV9ioBEzemDfYDshPEg%40mail.gmail.com
>> 
>> .
>>
> --
> --
> 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] Re: [v8-dev] Intent to Ship: Promise.allSettled

['Mathias Bynens' via v8-users]

LGTM

On Wed, Apr 24, 2019 at 6:01 AM 'Benedikt Meurer' via v8-dev <
v8-...@googlegroups.com> wrote:

> LGTM!
>
> On Wed, Apr 24, 2019, 02:05 Adam Klein  wrote:
>
>> LGTM!
>>
>> On Tue, Apr 23, 2019 at 4:19 PM Sathya Gunasekaran 
>> wrote:
>>
>>> 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-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-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] Re: Does 'eval' has the same performance as an explicit Script->Compile->Run pipeline?

['Mathias Bynens' via v8-users]

The document you linked to is outdated. It was based on Crankshaft which
hasn't been used since V8 v5.9.

See the first two lines:

*All this is wrong in TurboFan. (Node 8+)*
*Please do not take anything written here as performance advice, this is
here for historical reasons.*

On Sun, Apr 14, 2019 at 11:36 PM Al Mo  wrote:

> I just found this:
> https://github.com/petkaantonov/bluebird/wiki/Optimization-killers
>
> So that kind of answers my own question. Still, if anyone wants to drop
> its two cents, I'll be glad to read.
>
> Still puzzled why I 'measure' the same performance on both cases. I'm
> doing millions of linear algebra operations. Also compared that to similar
> C and performance is pretty close. If this means they could be even faster
> then wow :D
>
> On Monday, April 15, 2019 at 12:28:03 AM UTC+3, Al Mo wrote:
>>
>> Let's say I have some code and I want to execute it, you could:
>>
>> (a) create a v8::Script, compile it and then run it,
>>
>> OR,
>>
>> (b) send the string to an active v8::Context and call eval(code) from
>> inside.
>>
>> I remember hearing that eval does not optimize code, but in my purely
>> empirical tests both scenarios seem to run code at about the same speed.
>>
>> But still the question is, are there differences in performance between
>> the two approaches? What other things should I expect to be different?
>>
>>
>> --
> --
> 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] How to use Chrome Dev Tools to debug a script in d8

['Mathias Bynens' via v8-users]

Does the documentation help? https://v8.dev/docs/inspector

On Mon, Apr 8, 2019 at 1:23 PM DaManuell  wrote:

> I successfully built d8.exe from sources
>
> I made a simple JavaScrit file called test.js:
>
> function test( obj ) {
>   return obj.prop + obj.prop;
> }
>
> I ran d8.exe with the command line bellow:
>
> d8 --enable-inspector --shell test.js
>
> I am able to call my test function from the d8 shell interface:
>
> V8 version 7.5.0 (candidate)
> d8> test( { prop:'a'} )
> "aa"
> d8> test( { prop:'ab'} )
> "abab"
> d8>
>
> Can I, and if so, how, debug test.js from the Chrome Dev Tools?
>
> --
> --
> 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: [blink-dev] Re: [v8-users] Intent to Ship: Numeric separators

['Mathias Bynens' via v8-users]

LGTM now that the conflict has been resolved!

On Thu, Mar 28, 2019 at 12:01 PM 'Sathya Gunasekaran' via blink-dev <
blink-...@chromium.org> wrote:

> 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 <
> gsat...@chromium.org> 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
> .
>
> --
> 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%2BM7yE0uhhY5SssaaKxF%2Bw-hY7ibSVd2fsbEPD3A6C%2BpLa1w%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.

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

['Mathias Bynens' via v8-users]

The v8-users mailing list is not the best place to discuss the design of
new ECMAScript language features. This proposal reached Stage 3 of the TC39
process  a long time ago, and
each design decision has since been revisited and reaffirmed during TC39
meetings. It’s time to ship it.

On Thu, Feb 21, 2019 at 1:07 PM J Decker  wrote:

> class xyz {
> x = isTrueFalse();
> #y = !x;
> }
>
> that would work in a class though?
>

The `x` in `#y = !x` would refer to the global `x` in this example. You
probably meant to refer to the `x` field above, which you can accomplish
with `#y = !this.x`.



>
>> On Wed, Feb 20, 2019 at 5:14 PM Adam Klein  wrote:
>>
>>> LGTM!!
>>>
>>> On Wed, Feb 20, 2019 at 12:20 PM 'Mathias Bynens' via blink-dev <
>>> blink-...@chromium.org> wrote:
>>>
 LGTM

 On Wed, Feb 20, 2019 at 8:58 PM Sathya Gunasekaran <
 gsat...@chromium.org> wrote:

> 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-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.
>
 --
 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/CADizRgaQiv2%3DmEtPOcprwkGg_KcxCfF7A%3DpPp6q-kCW%3DGN2Mtw%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.
>>> 

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

['Mathias Bynens' via v8-users]

LGTM

On Wed, Feb 20, 2019 at 8:58 PM Sathya Gunasekaran 
wrote:

> 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-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: [blink-dev] Re: [v8-dev] Intent to Ship: RegExp @@matchAll / String.prototype.matchAll

['Mathias Bynens' via v8-users]

LGTM∞

On Fri, Dec 14, 2018 at 7:37 AM Jakob Gruber  wrote:

> LGTM3
>
> On Fri, Dec 14, 2018 at 1:57 AM Adam Klein  wrote:
>
>> LGTM2
>>
>> On Thu, Dec 13, 2018 at 3:27 PM Sathya Gunasekaran 
>> wrote:
>>
>>> 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.
>>>
>>> --
>>> 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/CAMd%2BM7zTAcnN5Aqwr1XdpBfd45Het_nOq2%3Deu6U_TvTRRDtVOQ%40mail.gmail.com
>>> .
>>>
>>> --
> --
> 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] runing v8

['Mathias Bynens' via v8-users]

https://v8.dev/docs/embed is a good place to get started.

On Thu, Dec 6, 2018 at 11:01 PM Idris AIT MOULAY 
wrote:

> hi every body there some one here that can help to understand v8 code
> source, and try to run it, there is any doc or reference that may help me
> to understand v8 code source.
>
> --
>
> AIT MOULAY Idris
>
> Software Developper
> P: (+212) 659-080966 <(+212)+659-080966>
> E: idris.aitmou...@gmail.com
> A: Casablanca, Maroc
> about.me/aitmoulay
>
> --
> --
> 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: [v8-dev] Re: Intent to ship: Intl.ListFormat

['Mathias Bynens' via v8-users]

LGTM2

On Thu, Nov 8, 2018 at 2:44 AM Sathya Gunasekaran 
wrote:

> 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-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: [v8-dev] Re: Intent to Ship: Public class fields

['Mathias Bynens' via v8-users]

With the upcoming (but separate) private fields proposal, the example
evolves from:

class IncreasingCounter {
  _count = 0;

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

...into:

class IncreasingCounter {
  #count = 0;

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

The example makes more sense in the context of that progression. (This is how
we explained the class features at Google I/O
.)

On Tue, Oct 23, 2018 at 1:11 PM  wrote:

> As exciting as this is, can anyone please explain why a feature called
> "public field" is being announced with properties prefixed by an
> underscore, which historically means "protected" or, to some extend,
> private property, in JavaScript-land ?
>
> This is a question specially for those that might decide to write some
> blog-post about this new feature: please don't use `_counter` or, if you
> like that, please explain that using `_` is just an author convention and
> it has nothing to do with the public field proposal itself.
>
> Thanks for your understating and for considering a better divulgation of
> such welcome news.
>
> Best Regards
>
> On Wednesday, October 17, 2018 at 9:47:04 AM UTC+2, Sathya Gunasekaran
> wrote:
>>
>> Contact Emails:
>> gsa...@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-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: [blink-dev] Intent to Ship: Public class fields

['Mathias Bynens' via v8-users]

LGTM

On Wed, Oct 17, 2018 at 9: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: well-formed JSON.stringify

['Mathias Bynens' via v8-users]

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 .

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.

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

['Mathias Bynens' via v8-users]

LGTM

On Fri, Sep 28, 2018 at 9:26 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
>
>
> --
> --
> 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-dev] Re: [v8-users] Re: Intent to ship: Intl.RelativeTimeFormat

['Mathias Bynens' via v8-users]

LGTM3

On Tue, Sep 25, 2018 at 10:46 AM Adam Klein  wrote:

> LGTM2
>
> On Tue, Sep 25, 2018 at 2:35 AM Sathya Gunasekaran 
> wrote:
>
>> 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.
>>
> --
> --
> 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] Intent to Ship: globalThis

['Mathias Bynens' via v8-users]

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.

Re: [v8-users] base64 encode/decode in v8

['Mathias Bynens' via v8-users]

`btoa` (and `atob`) are indeed browser-specific APIs; they’re not part of
ECMAScript and not implemented in V8.

You could use a JavaScript implementation.
https://github.com/mathiasbynens/base64 matches the browser APIs `btoa` and
`atob` as closely as possible.

On Mon, Aug 20, 2018 at 8:26 PM Gautham B A 
wrote:

> Hello folks,
>
> I was wondering if there's any v8 API that allows one to do base64
> encoding/decoding. Browsers have window.btoa, but it's not part of the
> global object in v8.
>
> Thanks,
> --Gautham
>
> --
> --
> 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] Is it possible to access the AST of the v8 engine, for a given JavaScript code?

['Mathias Bynens' via v8-users]

Grab a debug build (not a release build!) and run d8 --print-ast foo.js.

On Thu, Jul 5, 2018 at 2:39 PM czczcheng  wrote:

> I want to analysis the javascript code and modify it in some cases.
>
> --
> --
> 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: Array.prototype.{flat,flatMap}

['Mathias Bynens' via v8-users]

For future reference: this landed

 in V8 v6.9.* and should thus be available in Chrome 69.



On Tue, May 29, 2018 at 4:22 PM Sathya Gunasekaran 
wrote:

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

['Mathias Bynens' via v8-users]




On Fri, Mar 2, 2018 at 8:25 PM 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] Re: [blink-dev] Intent to ship: JSON ⊂ ECMAScript

['Mathias Bynens' via v8-users]

For future reference: this landed

 in V8 v6.6.257 and should thus be available in Chrome 66.

On Fri, Feb 16, 2018 at 7:58 PM, Benedikt Meurer 
wrote:

> LGTM!
>
>
> On Fri, Feb 16, 2018 at 7:57 PM Sathya Gunasekaran 
> wrote:
>
>> 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] Re: [blink-dev] Intent to ship: JSON ⊂ ECMAScript

['Mathias Bynens' via v8-users]

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 emailsmath...@chromium.org
>> Spechttps://github.com/tc39/proposal-json-superset
>> SummaryA Stage 3 proposal
>> makes ECMAScript a syntactic superset of JSON by allowing U+2028 and U+2029
>> in string literals.MotivationECMAScript 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 riskFirefox:
>> Public supportEdge: Public supportSafari: Public supportWeb developers:
>> Strongly positiveCompatibility riskThis 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
>> bughttps://bugs.chromium.org/p/v8/issues/detail?id=7418
>> Link to entry on the
>> Chrome Platform Status
>> dashboardhttps://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/ch
>> romium.org/d/msgid/blink-dev/CAJYpFjDOzdTHBNJR0oheBPOtKCETJQ
>> UxPqd3pYCz3DA8%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.

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

['Mathias Bynens' via v8-users]

For future reference: this landed

in V8 v6.6.253 and should thus be available in Chrome 66.


On Fri, Feb 9, 2018 at 11:44 PM, Adam Klein  wrote:

> LGTM3!
>
> On Fri, Feb 9, 2018 at 12:52 PM, Sathya Gunasekaran 
> wrote:
>
>> 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/propos
 al-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/f
 eatures/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.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe 

Re: [v8-users] --print-code does not work

['Mathias Bynens' via v8-users]

Tracking issue for the removal of --print-code:
https://bugs.chromium.org/p/v8/issues/detail?id=7437

On Fri, Feb 9, 2018 at 11:22 PM, Jakob Kummerow 
wrote:

> If --print-opt-code prints nothing, then probably your function isn't
> getting optimized. Try calling it more often.
>
> --print-code is "technically correct" in the sense that it prints all of
> the unoptimized machine code that V8 doesn't generate any more ;-)
> (We should remove the flag.)
>
>
> On Fri, Feb 9, 2018 at 1:18 AM Istvan Tabanyi 
> wrote:
>
>> Hi,
>>
>> I compiled v8 from sources successfully, but
>> --print-code/--print-opt-code gives me no output at all.
>> --print-bytecode works fine, --print-all-code prints something, but the
>> actual code is definitely not in the output(Created a simple function with
>> unique name, called in a loop, grepped for it and nothing)
>>
>> Tried release and debug builds, also with custom options like this:
>> gn gen out.gn/x64.debug --args='is_debug=true target_cpu="x64"
>> v8_target_cpu="x64" v8_enable_disassembler=true'
>>
>> I tried to look for tutorials on this topic, but most of it really
>> outdated and using make/gyp.
>> Can someone give me some tips about this? And sorry if this is not the
>> right place to ask questions like this.
>>
>> --
>> --
>> 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] Intent to Ship: Array.prototype.values

['Mathias Bynens' via v8-users]

Third time’s the charm! 爛

On Wed, Jan 31, 2018 at 4:07 PM, Sathya Gunasekaran 
wrote:

> 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 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] Bug in v8/src/parsing/scanner?

['Mathias Bynens' via v8-users]

On Fri, Dec 15, 2017 at 4:44 PM, J Decker  wrote:

> The code below comes from ScanString()
> I noticed that if the scanner encounters a '\' before a c0 > kMaxAscii
> HandleLeadSurrogate() (0xd800+0xdc00 surrogate handling) is no longer done.
>
> I tried to make a test file that had such things, but node failed to read
> utf-16 encoded file even with BOM marks...
>

I’m not sure what you mean exactly, but it sounds like you could use
`eval()` to test this more directly.


> But also, if there is no backslash, then PS and LS (0x2028, 0x2029)
> characters are not considered valid line ending and would be stored in the
> string literal (IsLineTerminator test)
>

This doesn’t seem to be the case:

$ rlwrap v8
V8 version 6.5.20
d8> eval('"a\u2028b"')
undefined:1: SyntaxError: Invalid or unexpected token
"a
^^
SyntaxError: Invalid or unexpected token
at (d8):1:1

  while (true) {
> if (c0_ > kMaxAscii) {
>   HandleLeadSurrogate();
>   break;
> }
> if (c0_ == kEndOfInput || c0_ == '\n' || c0_ == '\r') return
> Token::ILLEGAL;
> if (c0_ == quote) {
>   literal.Complete();
>   Advance();
>   return Token::STRING;
> }
> char c = static_cast(c0_);
> if (c == '\\') break;
> Advance();
> AddLiteralChar(c);
>   }
>
>   while (c0_ != quote && c0_ != kEndOfInput && !IsLineTerminator(c0_)) {
> uc32 c = c0_;
> Advance();
> if (c == '\\') {
>   if (c0_ == kEndOfInput || !ScanEscape()) {
> return Token::ILLEGAL;
>   }
> } else {
>   AddLiteralChar(c);
> }
>   }
>
>
> --
> --
> 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] How to build a fixed version of V8 and its dependencies.

['Mathias Bynens' via v8-users]

This is not a direct answer to your question, but we already host prebuilt
`d8` binaries for Linux on 32-bit and 64-bit architectures. We plan on
doing the same for other operating systems:
https://bugs.chromium.org/p/v8/issues/detail?id=5918 By using a precompiled
binary, you could bypass compiling from source together.

On Mon, Nov 27, 2017 at 12:19 PM, Edd Barrett  wrote:

> Hi,
>
> I raised this as a bug, but was asked to re-post here.
>
> For a benchmarking experiment I need to build a frozen version of V8. For
> most VMs this means just checking out a specific git version of the code
> and building it. For V8 it is complicated by the depot_tools system. I've
> yet to find a reliable way to do this.
>
> In the past, I've gotten by with cloning a specific version of depot
> tools, fetching V8, then walking the dependencies resetting the git
> versions of everything to a fixed date (this hack is needed because `fetch`
> gets moving targets). When this stopped working (it was a hack anyway), I
> resorted to rolling my own tarballs, which is not really ideal either.
>
> Is there an official way to build an frozen version of V8? How do you guys
> build (e.g.) V8-5.8.283.32 and using the dependencies of the time of that
> release?
>
> Without the ability to do this, it's difficult to conduct repeatable
> benchmarking experiments on V8.
>
> 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.
>



-- 

Mathias Bynens |  V8 |  Google Germany GmbH |  Erika-Mann-Str. 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.

-- 
-- 
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] Re: Intent to ship: Unicode property escapes in regular expressions

['Mathias Bynens' via v8-users]

For future reference: this landed

in V8 v6.4.276 and should thus be available in Chrome 64.


On Thu, Nov 9, 2017 at 10:48 PM, Adam Klein  wrote:

> LGTM (for v8 signoff purposes).
>
> On Thu, Nov 9, 2017 at 1:38 PM, 'Mathias Bynens' via blink-dev <
> blink-...@chromium.org> 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.
>>
>> On Thu, Nov 9, 2017 at 10:29 PM, Mathias Bynens 
>> wrote:
>>
>>> Contact emails
>>>
>>> yang...@chromium.org, math...@chromium.org
>>>
>>> Spec
>>>
>>> https://github.com/tc39/proposal-regexp-unicode-property-escapes (stage
>>> 3 proposal)
>>>
>>> Summary
>>>
>>> The Unicode Standard assigns various properties and property values to
>>> every symbol. For example, to get the set of symbols that are used
>>> exclusively in the Greek script, search the Unicode database for symbols
>>> whose Script property is set to Greek.
>>>
>>> Unicode property escapes are a new type of escape sequence available in
>>> regular expressions that have the u flag set. They enable querying the
>>> Unicode database for certain properties and values.
>>>
>>> E.g. /\p{Script=Greek}/u.test('π') === true
>>>
>>> Link to “Intent to Implement” blink-dev discussion
>>>
>>> There was none.
>>>
>>> Is this feature supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes.
>>>
>>> Demo link
>>>
>>> None. The explainer in the proposal offers some examples.
>>>
>>> Interoperability and Compatibility Risk
>>>
>>> In regular expressions without the u flag, the pattern \p is an
>>> (unnecessary) escape sequence for p. Patterns of the form \p{Letter}
>>> might already be present in existing regular expressions without the u
>>> flag, and therefore we cannot assign new meaning to such patterns without
>>> breaking backwards compatibility.
>>>
>>> For this reason, ECMAScript 2015 made unnecessary escape sequences like
>>> \p and \P throw an exception when the u flag is set. This enables us to
>>> change the meaning of \p{…} and \P{…} in regular expressions with the u
>>> flag without breaking backwards compatibility.
>>>
>>>
>>>-
>>>
>>>Edge/Chakra: public support; tracking issue:
>>>https://github.com/Microsoft/ChakraCore/issues/2969
>>>
>>>-
>>>
>>>Firefox/SpiderMonkey: public support; tracking issue:
>>>https://bugzilla.mozilla.org/show_bug.cgi?id=1361876
>>>
>>>-
>>>
>>>Safari/JavaScriptCore: shipped in Safari Technical Preview 42;
>>>tracking issue: https://bugs.webkit.org/show_bug.cgi?id=172069
>>>-
>>>
>>>Web developers: positive signals
>>>
>>>
>>> Is this feature fully tested?
>>>
>>> Yes. In addition to V8’s own tests (v8/test/mjsunit/harmony/regex
>>> p-property-*.js), Test262 includes tests for this feature
>>> 
>>> .
>>>
>>> OWP launch tracking bug
>>>
>>> https://bugs.chromium.org/p/v8/issues/detail?id=4743
>>>
>>> Entry on the feature dashboard 
>>>
>>> https://www.chromestatus.com/features/6706900393525248
>>>
>> --
>> 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/ch
>> romium.org/d/msgid/blink-dev/CADizRgbnTY1wLi6ZrF4_w74-PyZSg
>> ZgUruJrP4Q6-O1i5t6aMg%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.

Re: [v8-users] Re: [blink-dev] Intent to Ship: RegExp named captures

['Mathias Bynens' via v8-users]

For future reference: this landed

in V8 v6.4.49 and should thus be available in Chrome 64.

On Wed, Oct 18, 2017 at 7:09 PM, 'Sathya Gunasekaran' via blink-dev <
blink-...@chromium.org> wrote:

> LGTM2
>
> On Wed, Oct 18, 2017 at 9:17 AM, Adam Klein  wrote:
> > LGTM!
> >
> > On Wed, Oct 18, 2017 at 12:16 AM, Jakob Gruber 
> wrote:
> >>
> >> Contact emails
> >> jgru...@chromium.org
> >>
> >> Spec
> >> https://github.com/tc39/proposal-regexp-named-groups
> >>
> >> Summary
> >> Named captures for ECMAScript regular expressions allow developers to
> >> create and refer to named capture groups.
> >>
> >> Interoperability and Compatibility risk
> >> This is a stage 3 feature. It adds support for new regular expression
> >> syntax to specify and reference named captures. Named captures are
> exposed
> >> through the result object returned by RegExp.prototype.exec; and
> >> RegExp.prototype[@@replace] is extended to support named captures.
> >>
> >> Webkit has shipped this in Safari Tech Preview Release 40.
> >> Firefox and Edge have not implemented this yet.
> >>
> >> All V8 and test262 tests pass.
> >>
> >> Will this feature be supported on all six Blink platforms?
> >> Yes.
> >>
> >> Tracking bug
> >> https://crbug.com/v8/5437
> >>
> >> Chrome Platform Status
> >> https://www.chromestatus.com/features/5653365786673152
> >>
> >> --
> >> 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/
> CAO%2B%2BDfJ-SuzQaxRWAOAkZF7OEM9k6U6oTqyUt-%2BgtLHp4kC5uw%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.
>
> --
> 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/ch
> romium.org/d/msgid/blink-dev/CAMd%2BM7x2wyh9WFKxXPFFVLs%2BN
> SOaCKTh6961ixje2vSo4mguZA%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: Unicode property escapes in regular expressions

['Mathias Bynens' via v8-users]

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.

On Thu, Nov 9, 2017 at 10:29 PM, Mathias Bynens 
wrote:

> Contact emails
>
> yang...@chromium.org, math...@chromium.org
>
> Spec
>
> https://github.com/tc39/proposal-regexp-unicode-property-escapes (stage 3
> proposal)
>
> Summary
>
> The Unicode Standard assigns various properties and property values to
> every symbol. For example, to get the set of symbols that are used
> exclusively in the Greek script, search the Unicode database for symbols
> whose Script property is set to Greek.
>
> Unicode property escapes are a new type of escape sequence available in
> regular expressions that have the u flag set. They enable querying the
> Unicode database for certain properties and values.
>
> E.g. /\p{Script=Greek}/u.test('π') === true
>
> Link to “Intent to Implement” blink-dev discussion
>
> There was none.
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> Yes.
>
> Demo link
>
> None. The explainer in the proposal offers some examples.
>
> Interoperability and Compatibility Risk
>
> In regular expressions without the u flag, the pattern \p is an
> (unnecessary) escape sequence for p. Patterns of the form \p{Letter}
> might already be present in existing regular expressions without the u
> flag, and therefore we cannot assign new meaning to such patterns without
> breaking backwards compatibility.
>
> For this reason, ECMAScript 2015 made unnecessary escape sequences like \p
> and \P throw an exception when the u flag is set. This enables us to
> change the meaning of \p{…} and \P{…} in regular expressions with the u
> flag without breaking backwards compatibility.
>
>
>-
>
>Edge/Chakra: public support; tracking issue:
>https://github.com/Microsoft/ChakraCore/issues/2969
>
>-
>
>Firefox/SpiderMonkey: public support; tracking issue:
>https://bugzilla.mozilla.org/show_bug.cgi?id=1361876
>
>-
>
>Safari/JavaScriptCore: shipped in Safari Technical Preview 42;
>tracking issue: https://bugs.webkit.org/show_bug.cgi?id=172069
>-
>
>Web developers: positive signals
>
>
> Is this feature fully tested?
>
> Yes. In addition to V8’s own tests (v8/test/mjsunit/harmony/regex
> p-property-*.js), Test262 includes tests for this feature
> 
> .
>
> OWP launch tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=4743
>
> Entry on the feature dashboard 
>
> https://www.chromestatus.com/features/6706900393525248
>

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