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 <s...@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 <s...@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 > <t...@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 <benja...@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.un...@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@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-platform > > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > > > -- > shu > > > > -- > shu _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
