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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to