Async Iteration is available on non-release-only, for testing purpose

Shu-yu Guo shu at mozilla.com
Mon Mar 27 16:38:50 UTC 2017


Cross-posting to firefox-dev.

TL;DR:

arai has done truly excellent feature work implementing the ECMAScript
Async Iteration proposal. It is gated to Nightly/DevEd only for content
code. We will also be turning off the feature in chrome code to prevent
accidental dependence. Both these restrictions will be lifted when the
proposal fully matures to be in the next standard.

*PLEASE DO NOT USE ASYNC GENERATORS IN CHROME CODE.*

On Mon, Mar 27, 2017 at 9:31 AM, Shu-yu Guo <shu at mozilla.com> wrote:

> I agree that disabling for chrome is the right thing here over prefs. I
> want Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and
> ready to play with -- asking folks to turn on prefs to do that is not the
> way to go here from my perspective.
>
> Benjamin's concern is legit, though, so let's disable it in chrome.
>
> On Mon, Mar 27, 2017 at 9:12 AM, Till Schneidereit <
> till at tillschneidereit.net> wrote:
>
>> I think disabling in chrome code is a good idea. We have done these kinds
>> of non-release-only features in the JS engine in the past, and it hasn't
>> always gone well precisely for the reasons that have you concerned. OTOH,
>> adding a pref is annoyingly complicated for JS engine features (we should
>> probably work on that!) and makes the feature much harder to test for web
>> developers. Perhaps for now disabling for chrome is really the right
>> trade-off?
>>
>> On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg <benjamin at smedbergs.us
>> >
>> wrote:
>>
>> > I am concerned about the accidental consequences of turning this on for
>> > nightly/aurora. What if we start writing browser code that relies on
>> these
>> > features which unexpectedly starts failing in beta?
>> >
>> > I presume the value of enabling this in nightly/aurora is that we can
>> get
>> > web developers to experiment and report bugs?  Is that something we can
>> do
>> > asking them to explicitly turn this on via pref? Or are you worried
>> about
>> > this feature accidentally breaking existing web content and you want to
>> get
>> > bug reports from normal users?
>> >
>> > Could we mitigate risk by disabling this feature in chrome code by
>> default
>> > until you're confident in its readiness to ship?
>> >
>> > --BDS
>> >
>> >
>> > On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa <arai.unmht at gmail.com>
>> > wrote:
>> >
>> > > I just landed the initial implementation of Async Iteration proposal
>> > > (async generator and for-await-of syntax), as non-release-only
>> feature.
>> > >
>> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1331092
>> > >
>> > > The implementation is only for the testing purpose (for finding spec
>> bug
>> > > etc), and the semantic change in the spec is highly expected.  They're
>> > not
>> > > yet ready for production usage, either in browser code or in
>> testcases.
>> > > Please wait for a while :)
>> > >
>> > > --
>> > >
>> > > arai
>> > >
>> > > _______________________________________________
>> > > dev-platform mailing list
>> > > dev-platform at lists.mozilla.org
>> > > https://lists.mozilla.org/listinfo/dev-platform
>> > >
>> > _______________________________________________
>> > dev-platform mailing list
>> > dev-platform at lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> _______________________________________________
>> dev-platform mailing list
>> dev-platform at lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>        shu
>



-- 
       shu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170327/0efc7f0f/attachment.html>


More information about the firefox-dev mailing list