<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Cross-posting to firefox-dev.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">TL;DR:<br><br>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.<br><br><b>PLEASE DO NOT USE ASYNC GENERATORS IN CHROME CODE.</b><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 9:31 AM, Shu-yu Guo <span dir="ltr"><<a href="mailto:shu@mozilla.com" target="_blank">shu@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Benjamin's concern is legit, though, so let's disable it in chrome.<br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 9:12 AM, Till Schneidereit <span dir="ltr"><<a href="mailto:till@tillschneidereit.net" target="_blank">till@tillschneidereit.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think disabling in chrome code is a good idea. We have done these kinds<br>
of non-release-only features in the JS engine in the past, and it hasn't<br>
always gone well precisely for the reasons that have you concerned. OTOH,<br>
adding a pref is annoyingly complicated for JS engine features (we should<br>
probably work on that!) and makes the feature much harder to test for web<br>
developers. Perhaps for now disabling for chrome is really the right<br>
trade-off?<br>
<br>
On Mon, Mar 27, 2017 at 7:56 AM, Benjamin Smedberg <<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>><br>
wrote:<br>
<div class="m_-7934983190442896921HOEnZb"><div class="m_-7934983190442896921h5"><br>
> I am concerned about the accidental consequences of turning this on for<br>
> nightly/aurora. What if we start writing browser code that relies on these<br>
> features which unexpectedly starts failing in beta?<br>
><br>
> I presume the value of enabling this in nightly/aurora is that we can get<br>
> web developers to experiment and report bugs? Is that something we can do<br>
> asking them to explicitly turn this on via pref? Or are you worried about<br>
> this feature accidentally breaking existing web content and you want to get<br>
> bug reports from normal users?<br>
><br>
> Could we mitigate risk by disabling this feature in chrome code by default<br>
> until you're confident in its readiness to ship?<br>
><br>
> --BDS<br>
><br>
><br>
> On Mon, Mar 27, 2017 at 10:33 AM, Tooru Fujisawa <<a href="mailto:arai.unmht@gmail.com" target="_blank">arai.unmht@gmail.com</a>><br>
> wrote:<br>
><br>
> > I just landed the initial implementation of Async Iteration proposal<br>
> > (async generator and for-await-of syntax), as non-release-only feature.<br>
> ><br>
> > <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1331092" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/s<wbr>how_bug.cgi?id=1331092</a><br>
> ><br>
> > The implementation is only for the testing purpose (for finding spec bug<br>
> > etc), and the semantic change in the spec is highly expected. They're<br>
> not<br>
> > yet ready for production usage, either in browser code or in testcases.<br>
> > Please wait for a while :)<br>
> ><br>
> > --<br>
> ><br>
> > arai<br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > dev-platform mailing list<br>
> > <a href="mailto:dev-platform@lists.mozilla.org" target="_blank">dev-platform@lists.mozilla.org</a><br>
> > <a href="https://lists.mozilla.org/listinfo/dev-platform" rel="noreferrer" target="_blank">https://lists.mozilla.org/list<wbr>info/dev-platform</a><br>
> ><br>
> ______________________________<wbr>_________________<br>
> dev-platform mailing list<br>
> <a href="mailto:dev-platform@lists.mozilla.org" target="_blank">dev-platform@lists.mozilla.org</a><br>
> <a href="https://lists.mozilla.org/listinfo/dev-platform" rel="noreferrer" target="_blank">https://lists.mozilla.org/list<wbr>info/dev-platform</a><br>
><br>
______________________________<wbr>_________________<br>
dev-platform mailing list<br>
<a href="mailto:dev-platform@lists.mozilla.org" target="_blank">dev-platform@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/dev-platform" rel="noreferrer" target="_blank">https://lists.mozilla.org/list<wbr>info/dev-platform</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-7934983190442896921gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="monospace"> shu</font><br></div></div></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="monospace"> shu</font><br></div></div></div></div>
</div>