爲什麼params關鍵字不是上下文的？

Question

我問的原因是，它只在方法參數聲明中有效，不是嗎？我試圖在函數體內創建一個名爲「params」的變量，但當然這不是什麼大問題，只是想知道MS選擇使其成爲全局關鍵字而不是上下文的原因。

Answer 1

tvanoffson的答案推測，很難做出「參數」的上下文。它實際上不會那麼難。考慮：

void M(params x) 

在這種情況下，假設我們要做的是首先嚐試找到一個類型'params'。如果我們能找到一個，那就太棒了，我們完成了。如果我們不能，那麼我們有一個問題。假設，而不是x它是

void M(params Int32) 

顯然，這是一個錯誤，但什麼錯誤？我們是否應該假設Int32是參數名稱，並提供錯誤「您缺少類型」？我們是否應該假設Int32是類型，並給出錯誤，指出該類型必須是數組類型，並且缺少標識符？我們是否應該給出一個錯誤，說沒有名爲'params'的類型？這裏做什麼是正確的？顯然我們可以找出一些東西，但不明顯。

這是錯誤的情況下，與上下文關鍵字棘手;獲得成功案例的工作其實非常簡單。

但實際上，它並不如此，它是難作出的上下文，因爲它使上下文不是一個真正的大贏。使「set」和「value」上下文相關是一個很大的勝利，因爲我們假設所有類型的人都希望使用「set」和「value」這樣的名稱來創建局部變量。 「params」甚至不是英文單詞，所以任何人都不想使用它。使其具有上下文關係沒有什麼大的好處，因此該功能的成本是不合理的。

Answer 2

params關鍵字似乎只在方法參數聲明中有用，但我實際上同意MS，不管怎樣，讓關鍵字用於實例名稱都不是一個好主意。

也許他們都保留有這樣的事情在C＃8.0的能力：

params Customers = DB.GetCustomerList(); 

，否則會將params在局部範圍內爲好。

Answer 3

關於任何其他關鍵字也可能會有同樣的問題。例如，爲什麼不是「class」上下文，因爲它只用於類聲明中？

給我一個關鍵字是一個關鍵字。我想這極大地簡化了編譯的詞法分析部分，而不必須知道上下文。

順便說一句，你可以使用@符號，讓你聲明瞭一個名爲「PARAMS」變量（或任何其他保留關鍵字）：

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

Answer 4

埃裏克利珀有一篇博客文章涉及contextual and reserved keywords及其歷史。雖然它沒有明確地解釋爲什麼params在保留列表中（它自1.0開始），這意味着它屬於一組保留字，它們將是hard以使上下文相關。