[cfe-dev] Deducing a partial specialization fails

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Tue May 28 16:39:49 PDT 2019


On Tue, 28 May 2019 at 16:17, Arthur O'Dwyer via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Tue, May 28, 2019 at 9:01 AM via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
>
>> Please consider the example here:
>>
>> https://godbolt.org/z/4AwrXz
>>
>> Clang up to version 3.9.1 and all recent versions of other compilers
>> accept the code. Clang version >=4.0 fails.
>> If you move the definition of AccessorPointersT to Foo, it works again
>> and the partial specialization is deduced correctly.
>> Is this a bug or a pedantic interpretation of the c++ standard by clang?
>>
>
> Well, the compiler appears to be right that the partial specialization is
> unreachable because the `IsConst` parameter can't be deduced.
> Suppose you instantiated `Foo<A>`, where `A` was a class type defined as
>
> struct A {};
> template<> struct Bar<A> {
>     template<bool> using AccessorPointersT = int;
> };
>
> Then `Foo<A>::AccessorPointersT<false>` and
> `Foo<A>::AccessorPointersT<true>` denote the same type (namely, `int`). So
> you can't use template "pattern matching" to differentiate them, because
> they're identical.
>
> (Would you expect the partial specialization to be chosen in this case? If
> so, what would you expect it to deduce for the actual value of `IsConst`?)
>
> If you move the definition of the AccessorPointers struct from Bar down
> into Foo, then I believe the problem goes away, as you indicate. In that
> case, `Foo<A>::AccessorPointersT<false>` and
> `Foo<A>::AccessorPointersT<true>` definitely denote different types, and so
> it's OK to use pattern matching on them.
>

Instantiating Foo<A> for the above A would be ill-formed. But Foo itself is
not, because it has valid instantiations (eg, Foo<int>).

It looks like we fail to properly take the deduction depth into account
when checking for deducibility of a dependent template specialization type,
and incorrectly treat all dependent-scope template specialization types as
non-deducible (rather than being "dependently deducible"). :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190528/1fcdf686/attachment.html>


More information about the cfe-dev mailing list