================ @@ -249,7 +249,10 @@ Attribute Changes in Clang (#GH106864) - Introduced a new attribute ``[[clang::coro_await_elidable]]`` on coroutine return types - to express elideability at call sites where the coroutine is co_awaited as a prvalue. + to express elideability at call sites where the coroutine is invoked under a safe elide context. + +- Introduced a new attribute ``[[clang::coro_must_await]]`` on function parameters to ---------------- vogelsgesang wrote:
What do you think about `[[clang::coro_await_elideable_argument]]`? I would slightly prefer this over `[[clang::coro_elideable_await_argument]]` because it is more similar to its sibling argument `[[clang::coro_await_elideable]]`, and the duality between the two arguments becomes more obvious already from their names. I think we should particularly try to avoid any name with `must` in its name. To me, `must` expresses a guarantee given by the compiler to the programmer (such as for the `[[musttail]]` attribute which will fail compilation in case the call cannot be tail-called), enforced by the compiler. However, this attribute behaves the other way around: It expresses a guarantee given by the programmer to the compiler, the compiler does nothing to check or enforce the correctness of it. https://github.com/llvm/llvm-project/pull/108474 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
