[llvm-bugs] [Bug 38044] New: clang fails to deduce the most specialized template definition when it's partialy specialized with multiple template template parameters

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Jul 3 11:31:18 PDT 2018


https://bugs.llvm.org/show_bug.cgi?id=38044

            Bug ID: 38044
           Summary: clang fails to deduce the most specialized template
                    definition when it's partialy specialized with
                    multiple template template parameters
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: michaelroynard at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

I was doing simple metaprogramming recently and wanted to code the "front"
helper: get the first type of a type list.
So I experimented on wandbox this code :

#include <type_traits>

template <typename... Ts>
struct type_list {
    static constexpr std::size_t size = sizeof...(Ts);
};

template <typename List, typename = void>
struct front {};

template <template <typename, typename...> class List, typename T, typename...
Ts>
struct front<List<T, Ts...>, std::enable_if_t<(List<T, Ts...>::size > 0)>> {
    using type = T;
};

template <typename List>
using front_t = typename front<List>::type;

There's nothing fancy (Please let me know if the code above is not legal C++).
Usage is :

static_assert(std::is_same_v<int, front_t<type_list<int, double>>>);

The problem is when I'm specializing with a template template like this :

template <typename, typename...> class List

Then clang throws it away and doesn't find anything.
However, if I specialize only with :

template <typename...> class List

Then it's fine and clang doesn't throw it away (but it's not ok because I can't
do what I want to do this way).

I think clang is wrong here and should consider this specialization.
It consistently fails since clang 4.0 haven't tested the version before) up
until trunk.

FWIW, both gcc and msvc compile it just fine.
Here's a godbolt repro : https://godbolt.org/g/M5fgbj

Please let me know if what I'm writing is not legal C++.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180703/6cbf3fca/attachment-0001.html>


More information about the llvm-bugs mailing list