Subject: Re: [std-proposals] Remove non-type template limitations for consteval functions
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2021-02-24 14:38:29
On Wed, Feb 24, 2021 at 6:59 AM Bastien penavayre via Std-Proposals <
> Currently, non-type templates still have several limitations:
> - must be structural (no private members)
> - no allocations even if the type has a constexpr destructor
> - can't contain floating point (double or float)
> - can't hold strings of the "const char *" form
> and so on...
> These limitations have a good reason behind them for templated class and
> function as they produce symbols in assembly and need to be resolved.
> But as consteval functions never produce assembly/symbols and will never
> be resolved by another translation unit than their own these restrictions
> should be lifted.
> What are your thoughts on this?
> Am I missing something?
Yes. You're missing that templates need not only name-mangling (hashing)
but also specialization-matching (identity comparison).
(ISTR Richard Smith had a great concise explanation of that somewhere,
maybe in a paper, more likely in an email thread I'll never find. There's a
hint of it in
The problem we're trying to avoid is:
At least when all the members of `Vec` are *public*, you can kind of squint
at it and say "okay, these two Vecs are noticeably *non-identical* even
though their values are *equal*." But when the members are inaccessible by
design, you can't use that excuse, and so you'll need to invent some new
philosophy of what it means for two values (or objects?) to be different.
This area got a lot of attention regrettably late in the C++20 cycle, and
in fact I wrote a paper recommending that class-type NTTPs be removed from
C++20. (It was not adopted, of course.)
Here are some papers and posts for you to read, in reverse chronological
STD-PROPOSALS list run by firstname.lastname@example.org
Standard Proposals Archives on Google Groups