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

Tooru Fujisawa arai.unmht at gmail.com
Wed Mar 29 08:19:26 UTC 2017


thanks for the input :)

re-landed them disabling on chrome/addon, with a test that checks they're not available on chrome code.

--

arai

> 2017/03/28 1:38、Shu-yu Guo <shu at mozilla.com>のメール:
> 
> 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




More information about the firefox-dev mailing list