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. :)

> We shouldn't limit people's use-cases just because we can't think of them, or how inadvisable they might seem. Instead, keeping the language as regular as possible keeps us all sane.

Well, to be fair, the static if proposal had a couple of Over The
Nuclear Weapons of My Friends opposition arguments, and
I asked what to do to get rid of that opposition in order to have the
most important bits of the facility, and then followed
that advice. I didn't have the luxury of getting adventurous and risk
leaving the partridge in a pear tree; I needed to get
the bird into my hand.