为什么 params 关键字与上下文无关？

Question

我问的原因是，它只在方法参数声明中有效，不是吗？我试图在函数体内创建一个名为“params”的变量，但这当然不是什么大问题，只是想知道 MS 选择将其设为全局关键字而不是上下文关键字的原因。

Answer 1

对于任何其他关键字也可以提出同样的问题。例如，为什么“class”不是上下文的，因为它只在类声明中使用？

对我来说，关键字就是关键字。我想它极大地简化了编译的词法分析部分，而不必具有上下文感知能力。

顺便说一句，您可以使用

@

符号来声明一个名为“params”的变量（或任何其他保留关键字）：

var @params = new int[] { 1, 2 };

Answer 2

tvanoffson 的回答推测很难使“params”具有上下文。其实并没有那么难。考虑：

void M(params x)

在这种情况下，假设我们要做的是首先尝试找到类型“params”。如果我们能找到一个，那就太好了，我们就完成了。如果我们不能，那么我们就有问题了。假设它不是 x 而是

void M(params Int32)

显然这是一个错误，但是什么错误呢？我们是否应该假设 Int32 是参数名称并给出错误“您缺少类型”？我们是否应该假设 Int32 是类型并给出错误，指出该类型必须是数组类型，并且您缺少标识符？ 我们是否应该给出一个错误，指出没有名为“params”的类型？在这里做什么是正确的？显然我们可以弄清楚一些事情，但并不明显。

上下文关键字比较棘手的是错误情况；让成功案例发挥作用实际上非常简单。

但实际上，与其说使其具有上下文“很难”，不如说使其具有上下文并不是一个真正的重大胜利。让“set”和“value”上下文化是一个巨大的胜利，因为我们假设各种各样的人都希望使用“set”和“value”等名称来创建局部变量。 “params”甚至不是一个英语单词，因此似乎不太可能有人想要使用它。使其与上下文相关并没有太大的好处，因此该功能的成本是不合理的。

Answer 3

上下文和保留关键字

及其历史。 虽然它没有明确解释为什么 params 位于保留列表中（自 1.0 以来一直如此），但这意味着它属于一组保留字，而这些保留字很难与上下文相关。

params 关键字看起来确实只在方法参数声明中有用，但我实际上同意 MS 的观点，无论如何，让关键字用于实例名称并不是一个好主意。

Answer 4

也许他们保留了在 C# 8.0 中拥有类似功能的能力：

params Customers = DB.GetCustomerList();

或者以其他方式在本地范围内允许

params

。