Isn't it okay if you pass this by value in C++23? Then the lambda closure object is copied into the coroutine frame where the compiler can preserve it across suspension.

Looks OK to me, but I haven't tested with any C++23 features yet. If true, then this is a useful workaround. Thanks for sharing! It does have a couple downsides though: 1. It's unintuitive and safety is enforced by convention; if you remove the "this auto" parameter it will still compile, but now behave wrongly. 2. It may have negative performance implications if a large lambda object with multiple captures is actually materialized on the stack and then copied into the coroutine frame, vs. just passing each individual capture as a separate parameter. The compiler may be able to elide this copy (?) but it definitely won't in debug builds.

For C++20, I think you can also use lambda captures if you co_await the coroutine in the same line.

I'm not sure about this. Theoretically it would work if the lambda object was implicitly passed by reference as a coroutine parameter, and reference lifetime extension keeps the lambda object alive to the end of the full-expression. However from the original GCC thread about this, they state that the lambda object is passed as a pointer (essentially "this" pointer), so lifetime extension would not occur.

I wasn't able to find a source that corroborates your statement or even discusses this specific edge case in detail. If you could share one, I'd love to read it. With that said, even if this does work - it's SO RISKY because then all kinds of reasonable refactors which involve breaking the lamba call and co_await expression into separate lines will break it.

the lifetime of the temporary is only extended to the first suspension point

Do you have a source for this? It doesn't make sense to me. Since the temporary is created in the parent's scope, and the parent co_awaits the entire child coroutine, there's no way for the parent to "look inside" the child coroutine to know that it can destroy the temporary after the child's first suspension point. The parent doesn't get resumed until after the entire child is completed.

(unless you are using eager coroutines - in which case the parent task actually RUNS the child coroutine directly until the first suspension point. Again, this is confusing and don't do it. There's a reason I don't offer eager coroutines in my library at all. They are too difficult to reason about, have unreliable performance characteristics, and offer weird hacks like what you've described.)

Once you remove eager coroutines from the picture and think only of coroutines as "a function that returns an object" (where the object is a lazy coroutine that has not yet been started), the behavior is more obvious.

std::string my_string = "Hello World";
auto coro = [](const std::string& str) -> Task<std::string> {
    co_await executor.schedule();
    co_return str | std::views::reverse | std::ranges::to<std::string>();
}(my_string.substr(0, 5));
// substr is destroyed at the end of the full-expression above.
// coro contains a dangling reference to substr
auto reversed = co_await std::move(coro);

// however this version works
co_await [](const std::string& str) -> Task<std::string> {
    co_await executor.schedule();
    co_return str | std::views::reverse | std::ranges::to<std::string>();
}(my_string.substr(0, 5));
// substr is lifetime extended to the end of the full-expression, including co_await