不同编译器下函数模板实例化的行为差异及相关标准合规性咨询

咱们先从代码核心逻辑和你的三个疑问逐一拆解分析：

一、bar定义中的enum_as_byte<EnumT>是否属于用户定义转换？ #

答案是不属于。用户定义转换需要类类型提供对应的转换构造函数或转换运算符，但代码里的enum_as_byte类模板仅内部定义了一个typedef，完全没有声明从EnumT到enum_as_byte<EnumT>的转换构造函数。也就是说，当调用bar<Foo>(Foo{})时，传入的Foo{}根本无法转换成enum_as_byte<Foo>类型——这个转换路径不存在，所以第二个bar函数模板（参数为enum_as_byte<EnumT>的版本）在重载决议阶段就应该被判定为不可行候选，不会参与最终的函数匹配。

二、哪些编译器（版本）的行为符合标准？ #

符合标准的编译器版本包括：

• x86-64 Clang 17.0.1
• x86-64 GCC 13.1/13.2
• x86 MSVC v19.latest

这些编译器的行为是正确的：它们都没有触发第二个bar函数里的static_assert（因为该函数不是可行候选，根本不需要实例化它的函数体）。其中Clang 17出现的deprecated警告，是因为它在检查参数类型的过程中实例化了enum_as_byte<Foo>的定义，而这个类内部的typedef用到了被标记为deprecated的enum_as_byte_check<true>特化——这个警告本身是合理的，并不违反标准。

不符合标准的编译器版本是：

• x86-64 Clang 16.0.0
• x86-64 GCC 12.3

它们错误地实例化了第二个bar函数的函数体，触发了static_assert。本质问题是这些编译器错误地将不可行的函数模板候选也进行了函数体实例化，而根据标准，只有可行候选才需要进一步处理。

三、标准中规定正确行为的相关段落 #

以下是C++标准中的关键条款：

1. 函数模板重载决议与可行候选：[temp.over]章节第2-6条，明确了在重载决议过程中，函数模板会先生成候选函数（替换模板参数），只有当实参能够转换为候选函数的参数类型时，该候选才会被保留为可行候选。不可行的候选不会进入后续步骤，也不需要实例化函数体。
2. 类模板实例化时机：[temp.inst]章节第1-3条，规定类模板的实例化仅在必要场景下触发（比如创建类对象、引用类成员、类类型被用作完整类型上下文时）。如果只是在函数参数中使用类模板特化（作为不完全类型），且该参数与实参不匹配，那么不需要实例化类模板的定义。
3. static_assert的触发条件：[temp.res]章节第8条，static_assert的断言条件只会在模板实例化时进行检查。如果函数模板没有被实例化（因为它不是可行候选），static_assert就不会被触发。

备注：内容来源于stack exchange，提问作者Vladislavs Burakovs