当不相关的类型定义为别名时,对函数的调用是不明确的

Call to function is ambiguous when irrelevant type defined as alias

看完一篇很棒的文章True Story: Efficient Packing我尝试自己实现元组作为练习:

#include <type_traits>
#include <utility>
#include <functional>

template< std::size_t I, typename T >
struct tuple_leaf { T value; };

template< std::size_t I, typename T >
T & get(tuple_leaf< I, T > & leaf)
{ return leaf.value; }

template< typename Is, typename ...Ts >
struct tuple_base;

template< std::size_t ...Is, typename ...Ts >
struct tuple_base< std::index_sequence< Is... >, Ts... >
    : tuple_leaf< Is, Ts >...
{
    using tuple_base_t = tuple_base;
    template< typename ...Args, typename = std::enable_if_t< (sizeof...(Ts) == sizeof...(Args)) > >
    tuple_base(Args &&... args)
        : tuple_leaf< Is, Ts >{std::forward< Args >(args)}...
    { ; }
};

#if 0
template< typename ...Ts >
struct tuple
    : tuple_base< std::index_sequence_for< Ts... >, Ts... >
{
    using tuple_base_t = typename tuple::tuple_base_t;
    using tuple_base_t::tuple_base_t;
    using tuple_base_t::operator = ;
};
#else
// terse
template< typename ...Ts >
using tuple = tuple_base< std::index_sequence_for< Ts... >, Ts... >;
#endif

template< typename ...Args >
tuple< Args &&... >
forward_as_tuple(Args &&... args)
{ return {std::forward< Args >(args)...}; }

#include <tuple>

int
main()
{
    tuple< int > t(1);
    auto f = forward_as_tuple(t);
    (void)f;
    return 0;
}

Live example

实施 forward_as_tuple 后,我决定将 tuple 类型的定义从 class 模板 更改为 别名模板 的基本 class 模板,因为我需要拆分成 class tuple 本身及其实现 class tuple_base 只是 std::index_sequence_for for variadic template type parameters pack — alias template 正是适合此目的的工具。这样做之后我得到一个错误(#if 0 案例):

error: call to 'forward_as_tuple' is ambiguous

我觉得很奇怪,因为 alias template 什么都不做,另一方面 forward_as_tuple 从同一个命名空间调用类型 - 我希望 ADL 应该肯定会为上述情况工作。

如何解释#if 1#if 0版本代码的区别?

Adl 在传递的类型和传递的类型的模板参数中查找。

元组非别名有它的类型和它自己作为寻找 ADL 的地方。

元组别名在其模板参数列表中有一个 std::index_sequence。这会导致 std::forward_as_tuple 除了您的 forward_as_tuple 之外还被考虑在内。他们是同样好的匹配,并且会产生歧义。

正如@Piotr 在上面的评论中指出的那样,tuple<std::string> 即使在非别名情况下也会出现此问题。