On Thu, Jan 21, 2021 at 1:06 PM Ville Voutilainen via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Thu, 21 Jan 2021 at 19:53, Gašper Ažman via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > I find myself agreeing with both camps here - but one of the camps is talking about design, and the other about language semantics, and they don't actually conflict.
> >
> > I personally find it extremely surprising that code guarded by if constexpr is not a parseable comment.
> >
> > I would underline that 3 times if I could (4's too much, 5's right out).
> >
> > Regardless of the inadvisability of the use of these semantics, I would consider fixing this a DR. It's breaking my intuition about what if constexpr does, which aught to be "this is a comment that parses for the purposes of figuring out where it ends".
>
> Intuition is nice and all that, but that description seems imprecise
> at best, and possibly incorrect at worst. An if constexpr
> is a pair of templated block statements. The usual template rules
> apply, like "there must be at least one valid specialization".
>
> Whether that's compatible with your description is another matter, and
> what that really means for a co_keyword in one of the branches
> and no co_keywords in another is another separate matter. :)

The thing is, `if constexpr` actually does work "correctly" with
regard to auto-deducing the return type of a function. A discarded
return statement doesn't count, so you can `if constexpr` return
different types. Given that, it would make some sense to make the
`co_` identifiers only create a coroutine if they are not discarded.