The more I stare at this the more I feel it's actually a missing feature in Future itself. It can be see in a plain Future + SKT example:
try {
Future->fail( "message", category => @details )->get;
}
catch {
# where's the details now?
}
If Future->get wrapped the additional results in some sort of exception object (with stringification overloading for back compat), then they'd be visible in $@:
...
catch {
say "The Future failure category was " . $@->category;
}
Having done that, then F-AA needs to do nothing further for the `await` case.
The other half of the problem, of how `async sub` can yield those, can also be solved if Future->fail($err) could recognise its own exception objects and unfold them again:
catch {
Future->fail($@);
}
would then be transparent to Future failures.
Since F-AA itself is transparent to non-stringy object references as exceptions, this behaviour would combine nicely, and pass additional results through without AsyncAwait.xs itself having to make special consideration of it.
I like this "no tricks up my sleeve" approach, as it allows other implementations to do the same thing, and helps limit the "unwarranted chumminess with Future implementation" problem.
--
Paul Evans
