似乎可以在这里回答的真正问题是关于此功能的历史，以便可以在上下文中理解任何编译器支持。

非类型模板参数类型的限制

人们长期以来一直希望使用类类型的非类型模板参数。那里的答案有些缺乏。真正使对此类模板参数（实际上是非平凡的用户定义类型）的支持变得复杂的是它们未知的身份概念：

struct A {/*...*/};
template<A> struct X {};
constexpr A f() {/*...*/}
constexpr A g() {/*...*/}
X<f()> xf;
X<g()> &xg=xf;  // OK?

我们如何确定是否X<f()>和X<g()>是同一类型？对于整数，答案在直观上似乎很明显，但是类类型可能类似于std::vector<int>，在这种情况下，我们可能拥有

// C++23, if that
using A=std::vector<int>;
constexpr A f() {return {1,2,3};}
constexpr A g() {
  A ret={1,2,3};
  ret.reserve(1000);
  return ret;
}

尽管两个对象具有不同的行为（例如，用于迭代器无效），但两个对象都包含相同的值（因此与进行比较==）这一事实尚不清楚。

P0732非类型模板参数中的类类型

的确，本文首先使用新的<=>运算符添加了对类类型非类型模板参数的支持。逻辑是，使该运算符默认的类是“透明的比较”（使用的术语是“强结构相等性”），因此程序员和编译器可以就身份定义达成一致。

P1185 <=> != ==

后来意识到，==出于性能原因，应该分别将其默认为默认值（例如，它允许提早退出以比较不同长度的字符串），并且根据该运算符重写了强结构相等性的定义（该符号与a一起免费提供）默认<=>）。这不会影响这个故事，但是如果没有它，这条线索是不完整的。

P1714 NTTP不完整，没有浮点，双精度和长双精度！

人们发现，类类型的NTTP和constexprstd::bit_cast的无关功能允许将浮点值走私到类似的类型内的模板参数中std::array<std::byte,sizeof(float)>。尽管存在and（given ）的事实，但这种技巧将产生的语义是，a的每种表示形式都float将是不同的模板参数。因此，建议使用这些语义直接将浮点值用作模板参数，以避免鼓励广泛采用这种hacky解决方法。-0.0==0.0float nan=std::numeric_limits<float>::quiet_NaN();nan!=nan

当时，（给出的template<auto> int vt;）x==y可能不同于的想法引起了很多困惑&vt<x>==&vt<y>，并且该提议被拒绝，因为它需要的分析要比C ++ 20所能提供的更多。

P1907R0非类型模板参数不一致

事实证明，这==方面存在很多问题。即使枚举（一直被允许作为模板参数类型）也可以重载==，而将它们用作模板参数则完全忽略了该重载。（这或多或少是必要的：这样的运算符可能在某些翻译单元中定义，而不是在其他翻译单元中定义，或者可能以不同的方式定义，或者具有内部链接等。）此外，实现需要对模板参数进行规范化它：将一个模板参数（例如，一个调用）与另一个模板参数（例如，一个显式专业化）进行比较将需要后者已经以某种方式被确定就前者而言，同时又以某种方式允许它们可能有所不同。

身份的概念已经与==其他类型有所不同。甚至P0732也意识到引用（也可以是模板参数的类型）未与之进行比较==，因为这当然x==y并不意味着&x==&y。未被广泛认可的是指向成员的指针也违反了这种对应关系：由于它们在不断求值中的行为不同，尽管比较了==，指向联合的不同成员的指针作为模板参数却是不同的，而指向成员的指针已强制转换为指向基类的点具有相似的行为（尽管未指定它们的比较，因此不允许将其作为常量评估的直接组成部分）。

实际上，GCC已在2019年11月实现了对类NTTP的基本支持，而无需任何比较运算符。

P1837从C ++ 20删除类类型的NTTP

这些不一致之处如此之多，以至于有人提议将整个功能推迟到C ++ 23。面对如此受欢迎的功能中的许多问题，委托一个小组来指定保存该功能所需的重大更改。

P1907R1（结构类型）

这些故事有关类类型的模板参数和P1907R0的其中保留了它的名字，但有替代它的身体修订浮点类型重新收敛的解决方案，以国家成员体评论说，曾经也被提交关于同一主题。（新的）想法是要认识到比较从未真正紧密相关，并且模板实参唯一性的唯一一致模型是，如果在恒定评估期间有任何区分它们的方法，则两个实参是不同的（具有前述的能力区分指向成员的指针等）。毕竟，如果两个模板参数产生相同的专业化，则该专业化必须具有一个 行为，并且必须与直接使用任意一个参数所获得的行为相同。

虽然希望支持各种各样的类类型，但是几乎可以在C ++ 20的最后时刻引入（或重写）新功能的唯一可靠支持的类就是那些每个值可以通过实现区分的对象可以通过其客户端区分的对象，因此，只有那些具有所有公共成员（递归地具有此属性）的用户才能区分。对此类结构类型的限制并不像对总体结构的限制那样严格，因为只要是constexpr，任何构造过程都是允许的。它还为将来的语言版本提供了合理的扩展，以支持更多的类类型，甚至std::vector<T>-再次通过规范化（或序列化）而不是通过比较（不支持此类扩展）进行比较。

通用解决方案

这种新发现的理解与C ++ 20中的任何其他事物均无关。使用此模型的类类型NTTP可能是C ++ 11（引入了类类型的常量表达式）的一部分。支持立即扩展到工会，但逻辑并不仅仅局限于阶级。它还确定，长期以来对模板参数（禁止指向子对象的指针或具有浮点类型）的禁止也是出于对混淆的动机，==并且这是不必要的。（虽然这并不让字符串文字是出于技术原因模板参数，它确实让const char*模板参数的点静态字符数组的第一个字符）。

换句话说，最终激发P1714的力量被认为是模板基本行为的不可避免的数学后果，而浮点模板自变量毕竟成为C ++ 20的一部分。但是，C ++ 20的原始提议实际上并未为C ++ 20指定浮点和类类型的NTTP，这使“编译器支持”文档变得复杂。