https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
Target Milestone|--- |10.2
Last reconfirmed| |2020-06-05
--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
There was a long discussion amongst the implementors at WG21 meeting in Prague
about what should be done for the closure object. The standard is really
silent about coroutines and lambdas except by inference (and different
implementors had made different inferences).
The end result of the discussion is that we should treat it the same way as a
class object (passing a reference to it to the traits, allocator lookup and
promise parameter preview).
current MSVC is the only implementation to have this complete, clang passes the
reference to the traits but not to the allocator / promise. GCC (current code)
passes the closure pointer to all three.
I posted a patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546299.html
to bring GCC up to date with the agreed interpretation.
After that, diagnostics will (as ever) be a QoI issue - as far as coroutines
go, the implementation makes use of the same lookup facilities as the rest of
the C++ FE (so we should expect a consistent behaviour in terms of
diagnostics).
(libraries like cppcoro etc. make heavy use of coroutine lambdas, so they are
certainly found to be viable).
