Ambiguous partial specialization on Clang 4.0 (trunk)

[brunocodutra]

Specializations of algorithms for hana::tuple fail with

ambiguous partial specializations of 'tag_of<boost::hana::tuple<>, boost::hana::when<true> >'
    struct tag_of : tag_of<T, when<true>> { };

on

$ clang --version

clang version 4.0.0 (trunk 291432)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[palebedev]

Looks like what I've already reported here:
http://lists.llvm.org/pipermail/cfe-dev/2017-January/052160.html

[ldionne]

Thanks for the heads up. I guess we still don't know whether the problem is with the library of the compiler?

[pfultz2]

You can see the commit for the change here: llvm-mirror/clang@89014aa

[palebedev]

I've pinged cfe-dev once more, hopefully they'll notice before clang 4 is released.

[ldionne]

Unfortunately, I'm tempted to think that it's Hana's fault. If so, that will require a significant change to the way dispatching is done across the library, and that'll be a breaking change. In any case, that'll have to wait for Boost 1.64. I'm still hoping that it's a Clang bug, but I'm not too hopeful.

[brunocodutra]

I'm also tempted to go with Clang on this one unfortunately. The mental model that I use is that one partial template specialization is only more specialized than another if it depends on less *types*, i.e. non type template parameters are *mostly* ignored. cppreference corroborates this mental model and also gives an example where it doesn't fit, but I think this particular example doesn't apply in this case. http://en.cppreference.com/w/cpp/language/partial_specialization#Partial_ordering That said, I wouldn't be too surprised to be proven wrong here.

[brunocodutra]

Taking a closer look into it, the simplified mental model that I mentioned doesn't help here, because it is only good to address the rule that

The type of a template parameter corresponding to a specialized non-type argument shall not be dependent on a parameter of the specialization.

The present case is more complex and involves non-deduced context in the partial specialization ordering of class templates, which is as hairy as it gets:

http://stackoverflow.com/questions/31497357/partial-specialization-ordering-with-non-deduced-context

I'm not too confident Clang is correct here anymore.

[palebedev]

This problem is complicated, indeed, as we're in underspecified area of the standard, but it looks like we're safe for now - the pattern in question is now part of clang tests: llvm-mirror/clang@ae0874f . I've verified that clang with this commit works again.

[ldionne]

That's great news, at least for now. Thanks a lot! I'll close this now.