为什么使用被认为是错误的无效概念答案

【问题标题】：Why the using of a noneffective concept regarded as ill-formed为什么使用被认为是错误的无效概念
【发布时间】：2020-06-15 09:47:54
【问题描述】：

[expr.prim.req]/6中提到的新发布的草稿：

如果将模板参数替换为需求会总是导致替换失败，程序格式错误；不需要诊断。 [ 示例：
template<typename T> concept C =
requires {
  new int[-(int)sizeof(T)];     // ill-formed, no diagnostic required
};
—结束示例]

但是为什么我们不能保证诊断总是失败，而不是跳过诊断呢？

【问题讨论】：

我知道你想说我可以删除第一行和最后一行的代码格式，但是由于SO markdown检查的限制，我莫名其妙无法提交...跨度>
现在好点了吗？ ...
@L.F.是的。谢谢！
问题是“为什么不需要诊断”还是“为什么我们不能允许它只评估为false”？
@T.C.你的意思是我错误地理解了“诊断”的含义？谢谢，我会重新检查一下，但暂时不会，因为在中国已经是 0:13。

标签： c++ templates require c++20 c++-concepts

【解决方案1】：

需求表达式几乎可以做任何事情。它们可以引发进一步的模板替换，通过任意数量的代码向外级联。回想一下，模板替换构成了Turning complete language。

因此，您要求编译器在给定一个图灵完备程序的情况下，证明是否有某些输入导致该程序格式正确。这只是对停机问题的重述。就像停止问题一样，在一些简单的情况下，程序很明显会停止/不停止。但是，当您处理图灵完备的语言时，它可能会变得任意复杂。

该标准不会强制编译器解决停机问题。

【讨论】：

在我看来，应该设计支持交叉编译的语言，以便构建过程是原始递归的，而不是图灵完备的。当然，除了资源限制之外，执行应该是图灵完备的，但是处理应该被分成一个构建过程，该构建过程保证在有限时间内完成（成功或不成功），并且在构建环境中没有无限的副作用，并且单独执行可以在单独的执行环境中执行的过程。构建过程中的图灵完备性是一个错误，而不是一个特性。
感谢您的解释。我只是一个高中生，所以也许图灵完备的东西暂时对我来说太模糊了。尽管如此，我仍然想问你，让它不正确和让总是失败的概念有效之间有什么区别？如果后者是真的，编译器会做任何额外的工作吗？
@supercat：你有没有评论错误的答案？这个问题与构建过程或交叉编译无关。
@JohnDing 也见What makes a language Turing-complete?
@JohnDing：停机问题是一个著名的编程问题。停止问题要求您设计一种算法，该算法采用程序并告诉您该程序是否会在所有可能的输入上停止。事实证明，不可能设计出适用于所有程序的算法。要求编译器检测永远不会计算为有效表达式的表达式是要求编译器解决停机问题。 C++ 标准不要求编译器做一些被证明不可能的事情。