This queue is for tickets about the Future-AsyncAwait CPAN distribution.

Report information
The Basics
Id:
129306
Status:
resolved
Priority:
Low/Low

People
Owner:
Nobody in particular
Requestors:
leonerd-cpan [...] leonerd.org.uk
Cc:
DBOOK [...] cpan.org
AdminCc:

BugTracker
Severity:
Wishlist
Broken in:
(no value)
Fixed in:
0.47



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
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.
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
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


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.