Does `return foo` not seemingly imply the implicit unwrapping is occuring *inside* the function?
> Note as well that `return await` introduces extra ticks, potentially slowing > down your code unnecessarily. I'm aware. BTW, it's not like the implicit `return` inside `try`/`catch`/`finally` couldn't invoke `.then` manually to dodge the tick penalty, and that's basically what I'm proposing. ----- Isiah Meadows [email protected] www.isiahmeadows.com On Sun, Sep 9, 2018 at 5:45 PM Jordan Harband <[email protected]> wrote: > > I think the explicit `await`, indicating you want to handle it in the `async > function`, is a much better way to do it. > > Note as well that `return await` introduces extra ticks, potentially slowing > down your code unnecessarily. > > On Sun, Sep 9, 2018 at 1:35 PM, Isiah Meadows <[email protected]> wrote: >> >> Yes, and I know it's a breaking change. And although ESLint does have >> a rule banning `return await` [1], they did have to fix it to account >> for the fact "fixing" the inconsistency breaks `try`/`catch`/`finally` >> [2]. >> >> I'm specifically proposing it to avoid the counterintuitive behavior >> that currently exists in that area, why the lint had to make the >> exception in the first place. >> >> I'm not familiar with a linter rule that addresses this issue, but it >> still reads very awkwardly when it works as advertised everywhere >> else. >> >> [1]: https://eslint.org/docs/rules/no-return-await >> [2]: https://github.com/eslint/eslint/issues/7581 >> >> ----- >> >> Isiah Meadows >> [email protected] >> www.isiahmeadows.com >> >> On Sun, Sep 9, 2018 at 3:49 PM Peter Jaszkowiak <[email protected]> wrote: >> > >> > So are you saying that `return promise` and `return await promise` should >> > have identical behavior in the context of an async function? >> > >> > Wouldn't that be a breaking change? And isn't it trivially solvable with a >> > linter rule? >> > >> > On Sun, Sep 9, 2018, 13:29 Isiah Meadows <[email protected]> wrote: >> >> >> >> I know this requires a bit of an exception, but I feel >> >> `catch`/`finally` should trigger when a promise `return`ed from an >> >> `async` function rejects. It just seems incredibly odd not to, since >> >> the usual intuition is that if an error occurs during the execution of >> >> a function, it's catchable by the parent via `try`/`catch`, even if >> >> it's a simple `return foo(...args)`. You see that a lot with the >> >> `return await foo(...args)` step necessary within `try`/`catch` blocks >> >> in async functions, but that's literally the only time that idiom is >> >> necessary - it's otherwise generally equivalent to `return >> >> foo(...args)` mod timings, including when returning directly outside >> >> them. >> >> >> >> Could you all in TC39 fix this to work a little more intuitively? >> >> >> >> ----- >> >> >> >> Isiah Meadows >> >> [email protected] >> >> www.isiahmeadows.com >> >> _______________________________________________ >> >> es-discuss mailing list >> >> [email protected] >> >> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
