Re: C++17 and "Alice in Wonderland"

From: Daniela Engert (dani_at_[hidden])
Date: 2021-03-24 17:26:47

Am 24.03.2021 um 14:38 schrieb Edward Diener via Boost:
> 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<class T, bool (*)(T)> 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
the old order and the new one.
> If I specify whatever<char const,nullptr> 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