C++转换运算符重载在std::variant中的意外匹配问题

基于C++23标准的GCC/Clang/MSVC最新正式版本，我们有如下测试代码，涉及转换运算符重载与std::variant的结合：

#include <iostream>
#include <variant>
#include <string>

struct C
{
    template <typename T> operator T () {return 0.5;}
    operator int () {return 1;}
    operator std::string () { return "";}
};

int main ()
{
    C c;
    std::cout << std::variant<int, double, std::string>{c}.index() << "\n"; // selects template
    std::cout << std::variant<int, std::string, double>{c}.index() << "\n"; // selects template
    // demand to use string, MSVC fails
    std::cout << std::variant<int, std::string, double>{std::in_place_index<1>, c}.index() << "\n";
}

疑问点 #

预期结果要么因歧义编译失败，要么若std::variant按声明顺序推导索引则选择int类型，但实际无论variant类型顺序如何，始终选择模板转换运算符。请问：

• 编译器行为是否正确？
• 如何解释该现象？
• 是否存在未定义行为？
• MSVC无法编译最后一行是否属于bug？

分析与解答 #

1. 编译器行为是正确的 #

根据C++标准的重载决议规则，模板转换运算符的优先级并非低于非模板版本，而是取决于转换的匹配程度：

• 对于std::variant<int, double, ...>中的double类型，模板转换运算符operator T()会被实例化为operator double()，这是精确匹配；而非模板的operator int()需要从int到double的隐式转换，匹配优先级更低。
• 对于std::variant<int, std::string, double>中的double，模板转换运算符实例化后仍是精确匹配，优先级高于int或std::string的非模板转换重载——因为当候选转换都能生成有效构造时，精确匹配的内置类型转换优先级高于用户定义的std::string转换。

std::variant的构造会选择最优转换对应的类型，而非按声明顺序选择，因此编译器始终选择模板转换运算符对应的double类型是符合标准的。

2. 现象的核心原因：重载决议的匹配优先级 #

C++重载决议中，转换运算符的选择遵循以下优先级顺序：

• 精确匹配（如模板转换到目标类型T，无需额外转换） > 用户定义的转换（如非模板的operator int()或operator std::string()） > 内置隐式转换。
• 只要模板转换运算符能生成与variant某一类型精确匹配的转换，它的优先级就会高于其他需要额外转换的非模板重载，因此会被选中，和variant的类型声明顺序无关。

3. 不存在未定义行为 #

所有编译器的行为都符合重载决议的标准规则，代码本身没有违反C++标准的未定义行为场景，属于合法的重载决议案例。

4. MSVC无法编译最后一行属于bug #

最后一行使用std::in_place_index<1>明确要求构造variant的第1个成员（即std::string），此时应该调用std::string的构造函数，传入C对象并通过非模板的operator std::string()完成转换。GCC和Clang都能正确处理这一逻辑，但MSVC错误地尝试匹配模板转换运算符，导致编译失败，这明显不符合标准，属于MSVC的实现bug。

内容的提问来源于stack exchange，提问作者Gene