On 3/24/2021 4:41 AM, Daniela Engert via Boost wrote:
Am 23.03.2021 um 21:13 schrieb Edward Diener via Boost:
I apologize for this non-Boost related post, but I ran into what I thought was a C++17 bug in clang ( also in vc++14.2 C++17 )...
In a template of form
template
whatever up until C++14, the function argument type in the non-type template parameter was never looked at in the deduction of type T because NTTPs weren't deemed dependent on placeholder types in their function arguments. Beginning with C++17, they are. Therefore you may get conflicting type deduction because the second, additional deduction path from the function argument type in the NTTP will never deduce a top-level cv-qualified T in case of non-reference-like arguments. But the first, formerly only deduction path, may. And therein lies the conflict in your example where T = const char in the first path and T = char is in the second.
Well, at least this is my understanding of P0172.
I appreciate your explanation, and the following is not directed at you personally:
What is there to deduce ? The deduction comes from the NTTP, no matter if you provide a T for the first template argument. The type of the second template argument needs to be deduced. And since it is type-dependent on the function argument it implies a deduction of type T as well. This is the dichotomy between
Am 24.03.2021 um 14:38 schrieb Edward Diener via Boost: the old order and the new one.
If I specify whatever
then T is 'char const'. It's right there in my instantiation. Making it impossible in this simple situation to specify the T type when it is a top-level const type can not be C++ in any logical sense. I also do not even begin to understand why 'bool (*)(char const)' becomes 'bool (*)(char)' in any logical world. The declared type is 'bool (*)(char)' in both cases, cv-qualification isn't considered here. This semantic property of function parameters has meaning only within function block scope (or function parameter scope, too? I need to check). And therefore T is deduced to 'char'. Clearly a char const is not the same as a char. Who in their right minds would make up a rule that says they are the same, whether in a function declaration or not ? They clearly are not, unless you are out to destroy the notion that top-level consts in function declarations mean anything.
I think this rule exists since the inception of C++. Ciao Dani
Honestly if this is now C++, something seriously has gone wrong AFAICS. No doubt I am missing something basic, but this is truly "Alice in Wonderland" stuff to me. OK, I have had my rant. In what I was working on I will just specify that T as a top-level const is disallowed. My design can get by on that, rather than come up with some tortured code that allows T as a top-level const in the sort of signature above which works in both C++14 and C++17 on up.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5