类模板默认构造函数参数引发诊断错误是否属于未定义行为？

在开发某库时，我简化出如下代码：

struct MainStream{} default_stream, custom_stream;
struct Stream2{} custom_stream2;

template <class StreamSelection>
class Manage {
    public:
    Manage(StreamSelection & out_stream = default_stream){ 
        // do something
    };
};

void test(void) {
    Manage <MainStream> s1_a; //ok: use default_stream
    Manage <MainStream> s1_b(default_stream); //ok: use default_stream
    Manage <MainStream> s1_c(custom_stream); //ok: use custom_stream
    Manage <Stream2> s2_a(custom_stream2); //ok: use custom_stream2
    //Manage <Stream2> s2_b; //diagnostic error if uncommented due the incompatible default argument.
}

这段代码的设计目的是：

• 当模板以MainStream实例化时，构造函数提供合法的默认参数；
• 当以其他类型实例化且未传入构造函数参数时，强制触发编译错误；
• 同时避免使用额外的模板特化来实现该逻辑。

目前这段代码在GCC（-std=c++11 -pedantic -Wall -Wextra）、CLANG和MSVC中都能正常编译并按预期运行，但我不确定这种实现是否涉及未定义行为。

我在C++11最终工作草案N3337的14.7.1第3点中找到相关描述：

除非调用的是函数模板显式特化或显式特化类模板的成员函数，否则当函数在需要默认参数值的上下文中被调用时，函数模板或类模板成员函数的默认参数会被隐式实例化。

但我不确定这是否匹配当前场景——我的问题核心是默认参数的类型兼容性，而非是否被实例化。另外补充说明：当类以MainStream以外的类型实例化时，未被使用的默认参数仍存在类型不兼容的问题。

这种实现不存在未定义行为，属于标准允许的合法写法。

核心依据：默认参数的实例化时机 #

根据你引用的C++11标准14.7.1第3点，只有当函数在需要用到默认参数的上下文被调用时，默认参数才会被隐式实例化。换句话说：

• 当你实例化Manage<Stream2>但只调用带参数的构造函数（比如s2_a）时，构造函数的默认参数部分根本不会被实例化，自然不会触发类型不兼容的错误——因为编译器不需要处理这个默认参数。
• 只有当你尝试调用不带参数的Manage<Stream2>构造函数（比如注释掉的s2_b）时，编译器才会去实例化默认参数，此时才会发现default_stream的类型MainStream&和构造函数参数要求的Stream2&不匹配，进而触发编译错误，这完全符合你的设计预期。

额外验证：标准对未使用默认参数的规定 #

C++标准并没有要求类模板成员函数的所有默认参数必须对所有模板实例化都合法，只要在实际需要使用该默认参数的场景下合法即可。未被使用的默认参数即使存在类型不兼容问题，只要没有被实例化，就不会违反标准。

你当前的写法完美利用了这一点：通过默认参数的条件实例化，既实现了针对MainStream的默认支持，又在其他类型无参数构造时触发错误，同时避免了模板特化的冗余代码，是一种巧妙的合法实现。

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