That makes sense to me I think. In certain circumstances though might it not be possible to detect that that work would be unnecessary? You'd have to know that there was no other code which would need to be executed first, which as I understand would mean that the microtask queue would have to be empty and you'd have to be suspended (or about to suspend) at an await. Is there any other code which would need to run? If not, could such a condition be detected and evaluation allowed to proceed synchronously as an optimization?
I'm actually trying to make a case for an alteration to the language, `for await? (const chr of input)` and associated changes to allow generators to return some step values (from next()) that are not wrapped in promises (when no async work was required to compute them). I know this would solve the problem (and I have benchmarks to back it up), but I've gotten pushback from delegates that there's no need to remove the extra asynchronicity because engines will just make the problem go away without the language needing to do anything at all. -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/3536636b-6881-4a6e-96e3-006a1de771e7n%40googlegroups.com.
