Bug #129306 for Future-AsyncAwait: Consider await at toplevel

Wed Apr 24 13:27:28 2019 leonerd-cpan [...] leonerd.org.uk - Ticket created

Subject:

Consider await at toplevel

Before async/await it's common at the toplevel of the main script, to write such code as $thing->do_something->then(sub { ... })->... ->get; I.e. to invoke ->get to force futures and wait for them. This is quite rude inside a module, but at toplevel of the main script is quite fine. If you want to make use of async/await syntax at toplevel of the script it seems annoying to have to (async sub { ...})->() wrap the entire program. We might offer a special-case exemption for `await` expressions directly inside PL_maincv, by allowing await $thing->do_something; at toplevel. Thoughts? -- Paul Evans

Tue Aug 20 12:43:18 2019 grinnz [...] gmail.com - Correspondence added

On Wed Apr 24 13:27:28 2019, PEVANS wrote: Show quoted text

> Before async/await it's common at the toplevel of the main script, to > write such code as > > $thing->do_something->then(sub { > ... > })->... > ->get; > > I.e. to invoke ->get to force futures and wait for them. This is quite > rude inside a module, but at toplevel of the main script is quite > fine. > > If you want to make use of async/await syntax at toplevel of the > script it seems annoying to have to (async sub { ...})->() wrap the > entire program. We might offer a special-case exemption for `await` > expressions directly inside PL_maincv, by allowing > > await $thing->do_something; > > at toplevel. > > Thoughts?

My feeling on this is that ->get is already straightforward to call at the top level, and this may introduce confusion in that "await $future" is already equivalent to "$future->await" outside of the context of this module, and we certainly don't want to encourage indirect object syntax. On the other hand, it may be useful for making code appear more uniform, and the relation to async/await is more obvious than the ->get method to those who aren't familiar with Future.

Tue Aug 20 12:43:18 2019 The RT System itself - Status changed from 'new' to 'open'

Tue Aug 20 12:50:23 2019 DBOOK [...] cpan.org - Cc DBOOK added

Sun Nov 29 17:22:53 2020 leonerd-cpan [...] leonerd.org.uk - Correspondence added

An initial implementation allowing this just for PL_main_cv seems quite simple. It is simply a compile-time trick to emit the optree for `EXPR->get`. One interesting cornercase it doesn't yet cover is the contents of an END block, in such code as: END { $chip and $chip->protocol->power(0)->get } as seen in many Device-Chip driver example scripts. Perhaps it should be permitted in this limited case as well. If so, it does begin to introduce a slippery slope; e.g. whether it should be allowed as a toplevel expression in other .pm files. -- Paul Evans

Mon Nov 30 17:52:03 2020 leonerd-cpan [...] leonerd.org.uk - Correspondence added

At least initially implemented now in Future-AsyncAwait 0.47. I may open additional tickets to consider such cornercases as `END` blocks, but for now this main one is done. -- Paul Evans

Mon Nov 30 17:52:03 2020 leonerd-cpan [...] leonerd.org.uk - Status changed from 'open' to 'resolved'

Mon Nov 30 17:52:04 2020 leonerd-cpan [...] leonerd.org.uk - Fixed in 0.47 added