[PATCH] D45121: [coroutines] Add noop_coroutine to <experimental/coroutine>

[Casey Carter via Phabricator via cfe-commits]

CaseyCarter accepted this revision.
CaseyCarter added inline comments.


================
Comment at: include/experimental/coroutine:288
+
+    coroutine_handle() {
+      this->__handle_ = __builtin_coro_noop();
----------------
EricWF wrote:
> GorNishanov wrote:
> > CaseyCarter wrote:
> > > CaseyCarter wrote:
> > > > GorNishanov wrote:
> > > > > EricWF wrote:
> > > > > > Can `__builtin_coro_noop` produce a constant expression?
> > > > > No. llvm generates this value, so from clang perspective, it is not a constant.
> > > > > At llvm level it is a private per TU constant, so invocations of noop_coroutine() in different TUs linked into the same program will return you different values.
> > > > If this class type is not literal - since there's no `constexpr` constructor - applying `constexpr` to the member functions on 278-283 is at best misleading and at worst ill-formed NDR due to http://eel.is/c++draft/dcl.constexpr#5.
> > > This constructor should be `_NOEXCEPT`, since it's invoked by `noop_coroutine` which is `_NOEXCEPT`.
> > Issue for Rapperswil? These constexprs were approved by LEWG/LWG in Jacksonville 2018
> @CaseyCarter: I'm not sure this is true. Clang seems to be able to evaluate constexpr member functions of a non-literal type so long as they don't depend on the "argument value" of `this`. Example:
> 
> ```
> struct T {
>   T() {}
>   constexpr bool foo() const { return true; }
> };
> T t;
> static_assert(t.foo(), "");
> ```
@EricWF Yes, thank you - I'm forgetting that an invocation of a `constexpr` non-static member function with a non-constant-expression implicit object parameter can appear in a constant expression if it doesn't perform lvalue-to-rvalue conversion on the implicit object parameter.

These `constexpr`s aren't ill-formed NDR, but they do seem pointless. The base class versions aren't `constexpr`, so I can only use these when I know the concrete type of my handle is `noop_coroutine_handle`, in which case I know the results and have no need to call them at run time *or* compile time.

*shrug* I suppose they do no harm.


https://reviews.llvm.org/D45121