Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Tiny. Super tiny patch. Barely anything to review. Allows co_return all by itself in a coroutine. As per P0057R2+
I don't fully get the rational for this. Which part of P0057R2 talks about this behavior?
Starting from P0057R2, wording stated: 8.4.4/1: A function is a coroutine if it contains a coroutine-return-statement (6.6.3.1), an await-expression (5.3.8), a yield-expression (5.21), or a range-based for (6.5.4) with co_await.
Before the Big Kona Keyword Rename of 2015, you had to have 'await' or 'yield' for a function to a be a coroutine. Now, since, co_return is only usable in coroutines, have a co_return also triggers the coroutine processing.
task<int> f() {
Do something (no await here)
#if 0 // not yet implemented
something with await
#endif
co_return 42;
}This is not the reason to have co_return, but, once we have it, I think using it as one of the indicators that a function is a coroutine is a reasonable approach.
Cheers,
Gor
Clang already treats functions with only co_return as coroutines, the diagnostic is a warning not an error. Although IMHO Clang should emit a warning in this case. Obviously it's a false positive in your above example; but in general writing coroutines w/o co_return or co_await is a misuse of coroutines.
Clang already treats functions with only co_return as coroutines, the diagnostic is a warning not an error. Although IMHO Clang should emit a warning in this case. Obviously it's a false positive in your above example; but in general writing coroutines w/o co_return or co_await is a misuse of coroutines.
I am not sure about that. Consider these examples:
Empty Generator
generator<int> g() { co_return; } // this is a generator representing an empty sequence.Without co_return being legal, you would need to do something like;
generator<int> g() {
if (0 != 0) co_yield 1;
}Or work in progress async function:
future<int> h() {
// TODO: add more stuff
co_return 42;
}would have to be:
future<int> h() {
// TODO: add more stuff
co_await std::experimental::suspend_never{}; // to squash the warning
co_return 42;
}I think coroutine by itself with just co_return is a reasonable approach. Besides, that is what the TS says :)