On Wed, Feb 24, 2021 at 6:59 AM Bastien penavayre via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Hi,
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 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1837r0.html#operator-template .)

The problem we're trying to avoid is:

https://godbolt.org/z/8e31x4

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 order:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1907r1.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1837r0.html

https://quuxplusone.github.io/blog/2019/07/04/strong-structural-equality-is-broken/

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf

HTH,

Arthur