śr., 24 lut 2021 o 21:39 Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Wed, Feb 24, 2021 at 6:59 AM Bastien penavayre via Std-Proposals <std-proposals_at_[hidden]> 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
>

Maybe this should be simply an error? If you use NTTPs that have a
custom equality operator.
I do not see a way that compilers could handle arbitrary values returned by it.

> HTH,
> Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals