Deducing class template parameters from variadic value-initialization (clang vs g++) [duplicate]

Question

Consider the following reduced example which can also be viewed at https://godbolt.org/g/Et56cm:

#include <utility>

template <class T> struct success
{
  T value;
  constexpr success(T &&v)
      : value(std::move(v))
  {
  }
  constexpr success(const T &v)
      : value(v)
  {
  }
};
template <> struct success<void>
{
};
template <class T> success(T /*unused*/)->success<T>;
success()->success<void>;

int main(void)
{
    auto a = success{5};        // works
    auto b = success{};         // works
    auto c = success{"hello"};  // works
    auto d = success(5);        // works
    auto e = success();         // FAILS!
    auto f = success("hello");  // works
    static_assert(std::is_same<decltype(a), success<int>>::value, "");
    static_assert(std::is_same<decltype(b), success<void>>::value, "");
    static_assert(std::is_same<decltype(c), success<const char *>>::value, "");
    static_assert(std::is_same<decltype(d), success<int>>::value, "");
    static_assert(std::is_same<decltype(e), success<void>>::value, "");
    static_assert(std::is_same<decltype(f), success<const char *>>::value, "");
    return 0;
}

What is surprising to me is that success() does not compile, yet success{} does. I have provided the template deduction guide success() -> success<void>, so I would have thought that success() would work as well.

Is this expected behaviour in the C++ 17 standard, or am I missing something?

Answer 1

This is a gcc bug (just filed 81486). When deducing success(), we synthesize an overload set which consists of:

// from the constructors
template <class T> success<T> foo(T&& ); // looks like a forwarding reference
                                         // but is really just an rvalue reference
template <class T> success<T> foo(T const& );

// from the deduction guides
template <class T> success<T> foo(T ); // this one is a bit redundant
success<void> foo();

And determine the return type as if it were invoked as foo(), which certainly should give you a type of success<void>. That it doesn't is a bug.