std：：reference_wrapper的隐式T&constructor是否会<T>使其使用起来很危险？

boost::reference_wrapper<T>有显式 T&构造函数，而std::reference_wrapper<T>有隐式构造函数。因此，在下面的代码中:

foo = bar;

如果foo是boost::reference_wrapper，代码将无法编译(这很好，因为reference_wrapper不具有与实际引用相同的语义)。

如果foo是std::reference_wrapper，代码将"重新绑定"foo对bar的引用(而不是像人们可能错误地期望的那样赋值)。

这可能导致难以捉摸的bug…考虑下面的例子:

在版本1.0的某个假想库中:

void set_max(int& i, int a, int b) {
    i = (a > b) ? a : b;
}

在新版本(1.1)中，set_max被转换为模板以接受任何宽度的整数(或UDT)，而无需更改接口:

template<typename T1, typename T2, typename T3>
void set_max(T1& i, T2 a, T3 b) {
    i = (a > b) ? a : b;
}

最后，在一些使用库的应用中:

// i is a std::reference_wrapper<int> passed to this template function or class
set_max(i, 7, 11);

在这个例子中，库在不改变调用接口的情况下改变了set_max的实现。这将无声地破坏任何传递std::reference_wrapper的代码，因为参数将不再转换为int&，而是"重新绑定"到悬空引用(a或b)。

我的问题:为什么标准委员会选择允许隐式转换(从T&到std::reference_wrapper<T>)而不是遵循boost并使T&构造函数显式?

编辑:(回应Jonathan Wakely提供的答案)…

最初的演示(在上面一节中)故意简洁地展示了一个细微的库更改是如何导致使用std::reference_wrapper给应用程序引入bug的。

下一个演示是为了响应Jonathan Wakely的观点，展示真实世界中合法使用reference_wrapper"通过接口传递引用"。

• 来自开发商/供应商A

类似于std::bind，但假装它专门用于某些任务:

template<typename FuncType, typename ArgType>
struct MyDeferredFunctionCall
{
    MyDeferredFunctionCall(FuncType _f, ArgType _a) : f(_f), a(_a) {}
    template<typename T>
    void operator()(T t) { f(a, t); }
    FuncType f;
    ArgType a;
};

• 来自开发商/供应商B

一个RunningMax函子类。在这个假想库的1.0和1.1版本之间，RunningMax的实现变得更加通用，而没有改变它的调用接口。对于本演示，旧的实现定义在名称空间lib_v1中，而新的实现定义在lib_v2中:

namespace lib_v1 {
    struct RunningMax {
        void operator()(int& curMax, int newVal) {
                if ( newVal > curMax ) { curMax = newVal; }
            }
    };
}
namespace lib_v2 {
    struct RunningMax {
        template<typename T1, typename T2>
        void operator()(T1& curMax, T2 newVal) {
                if ( newVal > curMax ) { curMax = newVal; }
            }
    };
}

• 最后但并非最不重要的是，上述所有代码的最终用户:

某些开发人员使用来自供应商/开发人员A和B的代码来完成某些任务:

int main() {
    int _i = 7;
    auto i = std::ref(_i);
    auto f = lib_v2::RunningMax{};
    using MyDFC = MyDeferredFunctionCall<decltype(f), decltype(i)>;
    MyDFC dfc = MyDFC(f, i);
    dfc(11);
    std::cout << "i=[" << _i << "]" << std::endl; // should be 11
}

• 最终用户按预期的方式使用std::reference_wrapper。

• 单独，所有代码都没有错误或逻辑缺陷，并且与供应商B库的原始版本完美配合。

• boost::reference_wrapper将在升级库时编译失败，而std::reference_wrapper会无声地引入一个可能在回归测试中捕获也可能不会捕获的错误。

• 跟踪这样的错误将是困难的，因为"重新绑定"不是valgrind等工具可以捕获的内存错误。此外，std::reference_wrapper误用的实际站点应该在Vendor B的库代码中，而不是最终用户的库代码中。

底线: boost::reference_wrapper通过显式声明其T&构造函数似乎更安全，并且可以防止引入诸如此类的错误。在std::reference_wrapper中删除显式构造函数限制的决定似乎是为了方便而牺牲了安全性，这在语言/库设计中应该很少发生。