缺少格式字符串参数不应该是编译时错误吗？

Question

在格式字符串的全文是静态的并且在编译时已知的情况下，丢失的格式字符串参数不应该是编译时错误，或者至少是警告吗？

ReSharper 捕捉到了这一点，但它只是一个带下划线的波浪线。我的印象是这会触发一般的编译时错误：

string x = string.Format("soeuotnh {0}");

有什么方法可以触发此类错误的警告，而不必通过 FxCop 或其他方式运行我的代码？即使是 C/C++ 编译器也会为如此明显的错误触发警告/错误（尽管它们通常不会检查类型安全）。

Answer 1

我已在 Microsoft Connect 上提交了考虑此功能的请求，因为我认为

• 答案说“如果代码路径不是很热，人们会更喜欢他们的代码在运行时编译并失败”是荒谬的，并且在非解释性语言中没有地位，尤其是在显式定义的强类型语言中没有这样的语言类型安全与 C# 一样重要。
• 说编译器在物理上无法（永远）在编译时推导格式字符串和参数数组的答案也是不正确的。是的，有时编译器无法在编译时推断出其中之一（或两者），并且对此无能为力，但很多时候，它可以使用完整的信息。
• 答案说这完全不是编译器的工作，只是因为规范没有提到对这种行为发出警告，而忽略了这样一个事实：规范是编译器应该实现的最低限度，并且编译器是免费的（并且确实事实上，在很大程度上）只要不与规范相冲突，就可以超越。
• 说 C 编译器不这样做的答案是完全错误的 - 我已经发布了其他例子。
• 说我发布的代码示例在运行时不会抛出异常的答案是明显错误的（尽管从那时起大多数已经被编辑过）。

归根结底，这是一种“是的，可以，不，不，也许应该”的情况。我试图确保我无法在编译器（不是第三方软件）中设置任何东西来使其警告更具攻击性，或者是否有某种方法可以更改我的代码以使其抛出异常（例如，将所有内容声明为 const），但事实证明（到目前为止）这是不可能的。无论 Visual Studio 团队对我在 MS Connect 上提出的问题有何反应，事实仍然是编译器肯定可以在编译时捕获大量字符串格式异常，这将是一个好处......但它仍然适用于VS 团队来确定它是否值得实施。