据我所知，第一个代码段格式不正确(需要诊断 )；编译器应该由于部分专业化(2)而拒绝该程序.

As far as I can tell, the first snippet is ill-formed (and a diagnostic is required); compilers should reject the program because of the partial specialization (2).

[temp.deduct.type]/18 在这里适用:

如果 P 具有包含< i> 的形式，并且 i 的类型不同从模板的相应模板参数的类型由封闭的 simple-template-id 命名，推论失败.[...]

If P has a form that contains <i>, and if the type of i differs from the type of the corresponding template parameter of the template named by the enclosing simple-template-id, deduction fails. [...]

标准中的关联示例使用功能模板，但在其他方面非常相似.

The associated example in the Standard uses a function template, but is otherwise very similar.

因此永远无法推导部分专业化(2)的模板参数，并且

So the template argument of the partial specialization (2) can never be deduced, and [temp.class.spec.match]/3 applies:

如果部分专业化的模板参数不能为归因于其 template-parameter-list 的结构和 template-id ，程序格式错误.

If the template arguments of a partial specialization cannot be deduced because of the structure of its template-parameter-list and the template-id, the program is ill-formed.

有趣的是，我找不到能诊断此问题的编译器，甚至找不到严格模式下的EDG.我们可以推测，大多数编译器作者认为在这里进行诊断不值得为执行检查付出努力.这可能意味着将来我们可能会看到以上段落中的要求从病态变为病态，无需诊断.但是，这纯粹是猜测.无论如何，我认为它永远不会变成格式良好；我想不出永远无法匹配的部分专业化的有效用途.

Interestingly, I couldn't find a compiler that diagnoses this issue, not even EDG in strict mode. We could speculate that most compiler writers consider the benefits of having a diagnostic here not to be worth the effort of implementing the checks. This could mean that we might see the requirement in the paragraph above change in the future from ill-formed to ill-formed, no diagnostic required. However, this is pure speculation. In any case, I don't see it ever changing to well-formed; I can't think of a valid use for a partial specialization that never matches.

[temp.deduct.type]/18 通过 CWG2091的分辨率进行了澄清.