On Sunday, 24 October 2021 11:01:45 PDT Michael Scire via Std-Proposals wrote:
> TheFirst Rule of Virtual (the destructor is virtual), your condition is a
> constant false.
>
> It is a requirement enforced via concept that the relevant types have no
> non-trivial destructors (the context for this is a microkernel slab heap
> for reference-counted objects), and so the default (constexpr) destructor
> is used.

All virtual destructors are non-trivial.... wait, this has changed in C++20.

> This seems valid to me given that known requirement, is it not?

Yes, but it's weird and quite restrictive a scenario.

> >Anyway, wouldn't it be better to have a static constexpr token getter
> > method that you can do if constexpr (requires {...}) on?
>
> As I said, `I have thought about e.g. if constexpr (requires {
> Derived::GetClassTokenStatic(); }),`
>
> This works -- but it means that there is the potential for
> GetClassTokenStatic() and GetClassToken() to disagree, which seems
> undesirable particularly in the context of people less knowledgeable about
> requirements than myself attempting to extend functionality with new
> objects.

Yes, but considering the level of complexity of the scenario you're proposing,
that wouldn't be a limitation.

Anyway, considering the other posters' solutions to check that the object is
constexpr-constructible, I would feel better if there way a blessed,
standardised way to spell it, instead of everyone rolling out their comma
operator expressions.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering