You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The guideline is clear to disallow reference parameters to coroutines. But the guidance is unclear about pointer params. I think pointer params should be allowed as they make the ownership requirement very explicit and it avoids binding references to temporaries and local variables (unless done explicitly).
Some patterns which are dangerous are:
wrapper functions unintentionally binding references to local variables.
task<int> coro(constint& a) { co_return a + 1; }
// stack-use-after-return.
task<int> wrapper(int a) { returncoro(a); }
These problems of unintentionally introducing dangling references is solved if the coroutine accepts the parameter as a pointer. Pointer forces L-values. It does not bind to temporaries (these need to named) and does not bind local variables (unless done explicitly).
It would be great if the guidelines could shed some light on these pattern.
More concrete problems which arise due to references include use withstd::function1, 2
The text was updated successfully, but these errors were encountered:
usx95
changed the title
Guidelines are unclear about pointer parameters to coroutines
[Proposal] Allow pointer parameters to coroutines.
Sep 26, 2023
usx95
changed the title
[Proposal] Allow pointer parameters to coroutines.
[Proposal] Allow pointer parameters to coroutines (CP.coro section)
Sep 26, 2023
https://github.com/isocpp/CppCoreGuidelines/blob/4b706d9d6d/CppCoreGuidelines.md#cp53-parameters-to-coroutines-should-not-be-passed-by-reference
The guideline is clear to disallow reference parameters to coroutines. But the guidance is unclear about pointer params. I think pointer params should be allowed as they make the ownership requirement very explicit and it avoids binding references to temporaries and local variables (unless done explicitly).
Some patterns which are dangerous are:
godbolt
godbolt
These problems of unintentionally introducing dangling references is solved if the coroutine accepts the parameter as a pointer. Pointer forces L-values. It does not bind to temporaries (these need to named) and does not bind local variables (unless done explicitly).
It would be great if the guidelines could shed some light on these pattern.
More concrete problems which arise due to references include use with
std::function
1, 2The text was updated successfully, but these errors were encountered: