因為您可以用，並且也是您的最佳選擇！之所以可用，是因為 C# 能夠很好地在 Mac、Linux、Android 和 iOS 上運行（對了，還有 Windows）；它可以在您最喜愛的編輯器上運行；它在一個穩定的企業級平臺上經過了充分的時間驗證；最為重要的是：它是完全開源的！之所以是您的最佳選擇，是因為 ...
因為您可以用，並且也是您的最佳選擇！之所以可用，是因為 C# 能夠很好地在 Mac、Linux、Android 和 iOS 上運行（對了，還有 Windows）；它可以在您最喜愛的編輯器上運行；它在一個穩定的企業級平臺上經過了充分的時間驗證；最為重要的是：它是完全開源的！之所以是您的最佳選擇，是因為 C# 是編程語言創新方面的領導者，是原生跨平臺移動應用程式的最佳選擇，並且還有很多的優點超乎您的想象。在本次 GOTO Copenhagen 2016 大會講演上，Mads Torgersen 邀請您一起來探索 C# 的核心，探究為什麼它仍然散髮著活力，並探尋未來 C# 的發展趨勢。
概述
我是 Mads Torgersen，就職於微軟的 C# 部門。我現在年紀大了，因此我隨身都穿著這件 T恤，上面印著我正在負責的項目和語言名稱，以防我忘掉它們。這裡我想談一談 C#，為什麼我要推薦用它來作為大家的首選編程語言呢（即使到目前為止您還沒有接觸過 C#）。
Stack Overflow - 最受歡迎和喜愛的技術
Stack Overflow 每年都會進行一次調查，詢問很多開發者們都關心的問題（當然，在很多方面這些問題都是很具有傾向性，是很不科學的）。您必須在 Stack Overflow 上才能參與。
C# 是一門被廣泛使用的編程語言（排行第四，排行前三當中有一門實際上並不屬於編程語言——我說的不是 JavaScript，我說的是 SQL）。可以看出，C# 是一門主流語言。
他們同樣還問開發者們：是否還想繼續使用目前正在用的語言，並讓人們投票出他們最喜愛的技術。C# 同樣也在這個列表當中。這說明人們都很喜歡 C# 這門語言。此外還有其他人們也喜歡的語言，但是您還可以註意到，這些語言中的大部門要麼就是受眾較少，要麼就是非常專業化，很多都是某種狂熱信仰的一部分了。在這兩個列表當中，只有少數才是用途廣泛、受人們高度喜愛的。很高興能看到 C# 位於這個列表的三大最受歡迎的技術之一，其中兩個是編程語言，並且* Python 也在這裡面*。
我們不斷思考我們的所作所為，怎樣才可能是正確的呢，怎樣才能讓我們在多年以後仍然喜歡它。似乎並不是所有人都用過 C#，因為很多人所在的公司已經有 10 年多的歷史了，裡面存在了很多的遺留代碼。目前 C# 仍然保持著活力，我們希望它能將這份活力保持下去。我們同樣也有各式各樣的想法，而這驅動了 C# 的演進。
我們非常渴望去演進 C#。如果您看過現代語言的演變進程的話（從少到多），就會明白我們積極保持語言現代化的目的所在了。作為參與編程語言演變的一份子，我們有些時候是推動者，有些時候是跟隨者，無論如何，我們都試圖讓 C# 成為程式員們如今的絕佳選擇之一。我們不應該搞所謂的「限定」，只局限於某幾個平臺，因為過去十年當中就有人這麼做了，結果可想而知。
我還想提一提 F#，因為這相當於是我們的姊妹語言，它非常受歡迎，因為它很輕巧、也很強大。F# 是一門功能強大的語言，我們在與 F# 團隊的合作當中獲益良多，並且它也給我們提供了很多設計靈感。
（說明：F#是由微軟發展的為微軟.NET語言提供運行環境的程式設計語言。它是基於Ocaml的，而Ocaml是基於ML函數程式設計語言的。函數編程是解決許多棘手問題的最好方法，但是，純函數編程並不適合常規編程。因此，函數編程語言逐漸吸收了命令式、面向對象的編程模式，不僅保持了函數編程範式，同時也混合了其他需要的功能，使函數編程編寫各種類型的程式都很容易。F# 就是這種嘗試的成功代表，比其他函數編程語言做得更多。F#主要是為瞭解決特定的某些複雜問題，所以本身定位使得VS沒有提供F#的ASP.NET/WPF/GDI+的模板，若要使用需要自己配置。所以，一般情況下都是用C#。）
時代在改變 - 為什麼要選擇 C#
在越來越多的場景當中，您都可以使用 C#來進行編程。我們正在努力地做出一種改變。C# 在 Windows 當中是一種很重要的主要編程語言，但同時，我們在其他平臺上仍然還非常稚嫩。至少大多數平臺是這樣。現在 C# 已經是所有平臺上可選的編程語言之一，這非常鼓舞人心，然而我們同時也有些頑固，此外這些平臺上也出現了各式各樣新穎的語言。這使得我們迫切地希望其他平臺上也能夠使用我們的語言。
我們已經很多次對我們的語言進行了演進。實現 C# 底層的編譯器和 IDE 技術（名為 Roslyn 項目）為 C# 的編程啟用了獨一無二的場景。其中一個好處是，我們將 C# 的核心從 Windows 和 Visual Studio 當中剝離了出來，這意味著 C# 能夠很容易地在其他 IDE 當中使用。您可以用自己喜愛的 IDE 或者編輯器來編寫 C# 代碼。
我們已經將 C# 從完全的專有技術轉變為了完全開放源代碼的技術了。這意味著每個人都能給 C# 貢獻代碼了，當然也已經很多人參與到這個項目當中來了。我們現在正在同社區展開交流，現在 C# 的演進非常迅速。因為現在這更像是一個協同項目了，而不是「微軟說怎樣就怎樣了」。這非常讓人興奮。現在語言的變革已經不再是三年才一代了。「這是我們努力的成果，希望您能喜歡它」，我們現在每天都在與社區討論未來的方向問題。我們隨時隨地都能夠在網上、Github 上得到反饋。因此，我們語言設計的質量也越來越高。
讓我們從 C# 的各個項目開始一一介紹。
無處不 C# - Xamarin
Xamarin 以前是一家獨立的公司。我們六個月之前收購了他們。這是一種使用 C# 來構建跨平臺應用的技術，用來製作原生的 Android 和 iOS 應用。它可以讓您使用相同的語言、相同的源代碼來構建絕大多數應用組件，從而能夠為多種不同的移動平臺編寫應用。
它適用於 iOS 和 Android，同樣也可以用在 Mac 之上，順便提一下，Windows 也可以使用。它可以創建高品質的原生 UI。有許多大型應用正在使用這門技術，因為它可以極大地減少單獨在這些平臺上編碼的工作量。它也允許您使用與後臺相同的語言，例如說 Java，不過 Swift 和 Objective-C 還未支持。它以支持的平臺量取勝，是一門實現應用的絕佳語言。
它基於 Mono 項目，這是多年以前從微軟離職的員工所實現的開源項目，並且一直維護，致力於能夠在其他平臺上也能夠使用 C#。雖然在微軟當中的我們有些固步自封，但是他們卻在我們之前看到了 C# 跨平臺的潛力，並實現了這個偉大的跨平臺項目。Xamarin 正是基於此而生的，您在 iOS 和 Android 應用商店當中看到的許多應用都是基於 C# 的，要麼是使用 Xamarin，要麼是使用 Unity，這應該是業界領先的游戲引擎。
無處不 C# - Unity
Unity 也是一個基於 Mono 的項目，它的 2D、3D 游戲引擎是用 C# 來編寫的。有很多游戲是用 C# 編寫的。
無處不 C# - .NET 核心
在微軟，我們正努力完善 .NET 核心，這是對整個 .NET 技術棧、運行時以及代碼庫等內容的全新實現，旨在保證輕量、並且可供服務端使用，並且可用作雲和伺服器工作負載。它是跨平臺的，適用於 Linux、Mac 和 Windows。我們在此之上還放置了 ASP.NET 框架，這是一個被廣泛使用的 Web 框架，目前您就可以在非 Windows 的機器上運行 ASP.NET 了，並且它還完全開源了！為什麼我們要建立一個單獨的核心呢？這將有助於您能夠構建更輕量的伺服器。
首先，我們移除了 UI 框架，但是 UI 框架能夠獨立部署。例如，您可以將運行時環境同代碼一併發佈；雲端無需安裝各式各樣的依賴文件。它擁有一個更優秀的架構，更適合微服務的部署。它同樣也致力於使我們的服務端平臺更加現代化。這些不同的 .NET 運行在不同的平臺上，如果沒有統一的部署，那麼隨著版本的擴散，一切就會變得非常的混亂，尤其是您作為第三方庫提供方的時候。您需要某種東西能夠跨平臺運行，以便解決您的問題。
我們同樣也實現了一個名為 「.NET 標準庫」的東西，我們提供了一個所有 .NET 平臺全相容的 API。如果您需要使用它的話，您可以直接在工具庫當中鏈接這個 .NET 標準庫即可，它將可以在所有平臺上運行。您也可以收回在 .NET 生態系統中隨處可用代碼的能力。我們將隨時對標準庫進行升級，包括引入新的核心基本庫，這樣您任意鏈接所需要的標準庫即可。因此 C# 能夠在很多地方運行，希望這能夠說服大家來嘗試 C#，因為這比以前有著更大的適用範圍。能夠實現這個著實讓人興奮。
Roslyn - C# 語言引擎
我想要多談論一些底層的內容，也就是談一談 Roslyn 項目。
我們對 C# 引擎進行了現代化。以前只有一個簡單的 C# 編譯器。它使用 C++ 編寫的，之後我們有了 Visual Studio，然後將 C# 集成了進去。然而這兩者使用 C# 的方式都不同，沒有任何的代碼共用，因此也沒有辦法知道對方的相關信息。如果有人想要使用 C# 相關內容的話，那就需要為之編寫一套工具，或者為它們自己的 IDE 來添加支持，這是一個很大的工作量。因為人們不得不重頭開始編寫，因為 C# 引擎對它們而言是個黑盒。這對我們來說也並不是讓人滿意的。
因此我們決定，是時候重寫編譯器了，我們不僅重寫了 C#，並且還採用了一些新的架構。用來實現 C# 語義的工具只能有一個。我們需要構建一個大家都可以使用的工具，以便滿足他們想通過 C# 實現某些功能的願望。這個工具與平臺無關，無論是什麼樣的平臺，比如說批處理過程、編譯器，還是某些類似 IDE 的互動式環境，都可以使用這個工具進行。這是一個很難的目標，它花費了我們大量的時間來實現，並且也投入了大量的人力。但是現在，我們推出了 Roslyn API，它切實滿足了我們所設定的目標。
大家都需要知道，絕大多數 C# 工具已完成 Roslyn 引擎的遷移，不過仍然有一些沒有。場下還有一位演講者 Ted Brangs 的項目就是例外，因為他是出於某些技術原因的考慮。我們的想法是，這裡是您需要用於實現 IDE 和編輯器的代碼庫。如果您需要使用不同類型的分析工具，那麼可以導入它們來對代碼中的問題進行分析。如果您想要對代碼進行操作的話，例如代碼遷移、代碼補全或者重構之類的操作，那麼您也可以使用它。如果您需要生成源代碼，那麼您也可以使用它。如果您需要實現更多互動式場景，例如腳本或者 REPL（比如說現在我們在 Visual Studio 當中包含了一個 C# REPL，它是在 Roslyn 的基礎上構建的），那麼這個引擎仍然能夠編譯代碼並完成輸出。
這裡是您所能夠實現的一個範例，也就是人們能夠用 Roslyn 做些什麼。這可能會導致編程語言相關的工具呈現爆炸式增長，因為人們現在可以更快地來對 C# 進行處理了。它能夠與 C# 很好地協同工作。現在您已經有很多可以輕易得到的信息了，比如說語法、語義等內容，您就可以按照自己的想法，向所需要的地方添加特定的位碼了。有一個社區項目充分利用了這點，那就是 OmniSharp。
（請記住：C#語言引擎--Roslyn）
OmniSharp - 隨時隨地可編輯 C#
OmniSharp 是一個特別的項目，旨在讓 C# 能夠在您喜愛的編輯器上運行。他們實現這個功能的方法很聰明：由於 C# 現在已經可以在任何地方運行了，因此他們採用 Roslyn C# 引擎，然後在一個單獨的進程中運行，不管您在進行開發的機器是什麼（例如一臺 Mac）。他們使用一個單獨的進程來運行引擎，然後剩下所需要做的就是添加一個很簡單的集成層，然後加入到特定編輯器中的集成層當中，這樣雙方便可以通過進程來進行通信，從而讓編輯器瞭解到 C# 的全部信息。
每次您按下了一個鍵，例如輸入了點語法，然後這個時候您需要顯示代碼補全，這個時候它就會詢問旁邊的進程：「用戶輸入了點語法，那麼我需要在代碼補全列表當中顯示什麼呢？」。Roslyn 知曉所有的語義，它隨後會告訴編輯器：「這五種方法是可用的，顯示它們即可」。
通過這種分離方式，使得所有的語義分析過程被包裹在單獨的進程當中進行，然後通過標準的數據傳輸方式來進行數據的交換。這使得我們可以在很多的編輯器當中去實現表現良好的 C#，並且還可以提供語義感知功能（當然，這種做法褒貶不一）。
我需要再提一點，對於微軟的 Visual Studio 而言，我們使用 OmniSharp 來實現其 C# 模式，因為這是一個擴展，可以在任何地方載入。它不會內置在編輯器當中。C# 就像其他語言一樣，對 Visual Studio 而言就是一個擴展組件。
(個人認為：OmniSharp項目對Roslyn引擎進行了封裝，以更方便的使第三方編輯器調用，比如自己開發一個C#代碼編輯器）
演示 - Roslyn 分析器
讓我們舉一個更具體的例子。為了幫助人們將重點放在語言實現之外的地方，我們創建了這個框架，名為 Analyzer，通過它可以輕鬆地對人們的源代碼進行分析、診斷，最後輸出結果。這樣，我們便可以提供代碼修正建議了。
如果您需要：
1、您的組織有需要強制執行的代碼格式
2、經常執行重構
3、想要與大家分享代碼
4、需要讓代碼修正自動化
那麼這個工具正是您所需要的。
這個項目您可以在 Visual Studio 當中安裝，然後就可以開始使用了。當您打開某個項目的時候，它就已經自帶了為這個項目而建立的樣板代碼。具體而言，當您的項目像這樣進入調試模式的時候，然後分析器便會提取您的代碼，然後進行代碼修正，最後將結果輸出。分析器可以以批處理代碼的方式運行，也可以將其作為 Nuget 包進行分發。它是以 Visual Studio 擴展程式的身份出現的，在 Visual Studio 的完整版本當中，它是作為調試模式的一部分運行的。現在我運行了 Visual Studio，然後它便開始執行代碼修正了。這個是我在完整版本當中的 Visual Studio 所編寫的操作。
現在讓我們在這個完整版本的 Visual Studio 中打開一些代碼。我還沒有完全實現完這些分析器的功能。這裡是一些我們想要進行操作的示例代碼。出於簡便起見，我想要實現的東西是語法分析，這裡我可以定義各種各樣的語義規則。Roslyn 引擎提供了完整的信息供我使用，我可以定義 if 或者 else 語句當中沒有柯里化（curlies）語句是非法的代碼樣式。
我們需要實現那種老式的、固化的代碼風格，也就是始終需要添加柯里化的語句，因為接下來編輯代碼的時候，並不會得到太多的 BUG。我們需要在某些情況下阻止這種代碼的出現，出於時間考慮，我這裡只對 if 進行實現，我們當然也可以將其應用到 else 規則當中來。這裡讓我們來實現一個小型的代碼分析器。
這裡我不會停止使用這個完整版本。我需要放置一個斷點。每當我們看到 if 語句的時候，最開始需要做的就是要註冊它，我們需要調用這個方法 AnalyzeNode。每當 Visual Studio 中的源代碼分析器命中了一個 if 語句，那麼就會自動前往這裡，然後我就可以執行一些操作了，隨後它就會繼續分析代碼，直到命中下一個斷點。現在我能夠得到這段代碼當中的全部信息了，接下來我就可以添加操作了。我得到的東西是一個 context 對象。
讓我們看一下這個 context 當中的內容。如果這個 if 語句不符合要求，我就可以報告一個診斷過程。我可以得到當前語法樹的相關節點，通常就是這個 if 語句當中的內容。讓我們開始處理吧，我們將滑鼠懸停在這個上面，由於我們位於調試模式，因此這裡可以看到一個實際傳入的對象。我們可以看到這裡的確就是一個 if 語句。讓我們使用 Roslyn 構建的對象模型，將其轉換為 if 語句模型。
這裡我能夠得到一個語法樹節點，它恰好是 IfStatementSyntax 的派生類。我們可以聲明 var ifStatement 賦值為該值。現在這就是我們之後唯一所需要調用的對象了，我這裡將不再檢查它是否是一個 if 語句。如果這個語句內部的東西不呈現柯里化的話，那麼這個東西將被稱為 Block，這就說明這段代碼是不符合規範的。如果它不屬於 SyntaxKind.Block 的話，接下來我就會提示錯誤了。我會告訴用戶：「這裡不對」。現在我需要彙報診斷結果。不過現在我還沒有實現，我需要進行一點重構操作，來為之生成一個局部變數。
我可以通過 Diagnostic.Create 創建一個診斷，它需要我提供一些參數。首先是一個被稱為 Rule 的描述符，然後我需要指定 location。也就是當問題出現的時候，我需要在代碼當中顯示波浪線。然後我需要指明當前違背了何種規則。然後指明不符合規則的位置。讓我們再對這段實現進行一下重構，生成一個局部變數。這就是我在調試模式全部所需要做的。
那麼什麼是所謂的「位置」呢？也就是我當前正在處理的這個節點：if 語句。那麼我們需要在那裡放置提示信息呢？讓我們放在這個 if 關鍵字上吧。if 語句這裡擁有一個 if 關鍵字，因為這是一個具體的語法樹。它擁有裡面代碼的全部實現細節，包括所有的位置。讓我們從中取得相關的位置。這裡通過 GetLocation 方法來獲取。我們得到 if 關鍵字的位置，然後將這個位置傳入到這個方法當中。我編寫了一些代碼。讓我們移除這個斷點，然後繼續在調試器當中運行。我們等待一會兒，看看發生了什麼，好的，現在您會看到 if 語句當中出現了波浪線。
這就是我的全部操作：編寫三四行代碼就可以識別出問題所在，並告訴框架在哪裡顯示這個問題。為了向您證明它能夠起作用，我把這段代碼註釋掉，您會發現現在波浪線消失了。
當您試圖實現更為複雜的操作的時候，就變得有點困難了，但是這仍然是一個相對簡單的語言模型，因為它包含了完整的語法和綁定語義，人們可以用它來構建工具，然後與別人分享，這樣便能夠讓每個人在編輯 C# 的過程當中遵循一致的原則，不管它們所用的編輯器是什麼，只要是基於 Roslyn 的就行。無論人們位於哪個平臺，他們都能夠從中收益匪淺。
我寫的這個分析器同樣可以在批處理模式當中運行。它可以成為編譯過程當中的一部分，可以標記警告或者錯誤，就如同編譯器所做的那樣。我還可以實現修複工具（但我之後的時間不打算演示這個功能），它可以基於我們制定的規則對代碼進行修複。
這就是 Roslyn 這邊的演示，它是如何幫助人們獲得更好的編碼體驗的，一個更好的 C# 開發體驗。它給予了我們更好的代碼庫，更好的架構，顯然在 C# 當中，我們可以對它進行 Dogfood 測試，以更好地幫助我們演進語言本身。
C# 的演進
如今我們對 C# 進行演進較以前已經容易很多了，並且我們可以讓社區通過貢獻代碼而參與到 C# 的演進當中來。然而，這些演進的版本（我不會把所有版本都列述一遍）——展現了我們在創新過程當中的破壞性。
我想以 Async 為例。我們編寫了 LINQ，也就是我們在 C# 版本 3 的時候引入的查詢操作。我們採取了一個很有趣的冷門語言所存在的概念，並嘗試將其主流化，將這些概念引入到 C# 這個主流語言當中，從而幫助它們開擴更廣闊的市場。C# 當中的 LINQ 查詢就是您能夠在其他函數式編程語言當中找到的一個例子。
我們把它們與 Lambda 表達式結合在一起。現在世界上絕大多數語言都可以使用 Lambda 表達式。當然幾年以前這並不常見。如今 Java 也可以使用 Lambda 了。當然，我們還是回到 C# 版本 2 來，在這個版本中我們引入了泛型，僅僅只是慢了 Java 一拍，但是泛型已經成為了 C# 必不可少的一部分。因為在 C# 當中，泛型是深嵌入運行時當中的。Java 則是採取了比較謹慎的方法，讓泛型直接編譯成所需要的東西。
當您將泛型機制實現在運行時當中的時候，這對獲取語義而言是 100% 有好處的，然而這同樣也意味著性能特性將截然不同，尤其是當語言中存在值類型的時候，當 C# 從版本 1 升級的時候就遇到這個問題，Java 可能會在未來採取這種方式來實現泛型。當語言當中存在值類型的時候，您希望泛型能夠識別出它們，並且專門為這些值類型設定特定的規則，也就是在使用泛型的時候就無需對其進行封裝和分配內容空間。這樣泛型就能夠讓代碼更快，而不是產生拖累。
自我們升級之後，泛型便成為了很多語言的標配特性。由於泛型的引進，我們藉此便能夠正確地實現查詢功能。由於泛型是深嵌入在運行時當中實現的，因此我們可以使用反射機制，這樣我們便可以實現一些奇怪的代碼引用，然後將 C# 代碼轉換為 SQL。這都是基於類型可以變換的機理才得以實現，並且甚至在運行時都是可以如此使用。
我們將動態值集成到了靜態類型的系統當中，這種類型的類型是動態的、變化的，我們稱之為 Dynamic。再次強調，其底層實現仍然是基於泛型來實現的，這使得其運行效率高效，並且避免了很多無謂的封裝操作。Async 則是深度依賴於泛型機制。在 C# 版本 6 當中，我們引入了 Roslyn，因此對於實現任何特定的語言特性而言，不再是一件難事。我們現在擁有了更多的靈活性，現在我們便可以實現那些還未實現的微小特性了，我們通過實現這些特性，可以使得開發工作更簡單、更優雅、更簡潔、更輕鬆。
之後我們在 C# 版本 6 當中引入了 swath ，也就是現在的 C# 版本。然後在之後的 C# 版本 7 當中，我們將再次引入一些更重要、更底層的特性，我們想要從函數式編程語言當中進行大量借用特性，我認為我們下一步可能是需要引入相關的特性，來處理那些不必用面向對象的方式處理的數據。大家都知道我們一開始是一門非常純粹的面向對象語言，然後只是傾向於添加一些函數式的特性來作為面向對象的一些擴充，並且我們也在嘗試將這兩者很好地結合起來。這個靈感來自於 Scala，並且 JVM 也在這麼做，嘗試將函數式和麵向對象結合起來，但是我們絕對不會拋棄面向對象這個根本。
（Scala是一門多範式的編程語言，一種類似java的編程語言，設計初衷是實現可伸縮的語言，並集成面向對象編程和函數式編程的各種特性。）
演示：Async
我打算跳過這個 Async 的演示，因為大多數人可能都知道它的作用是什麼了。那麼讓我們來談一談即將到來的 C# 版本 7。
（C# 1.0 with Visual Studio.NET
C# 2.0 with Visual Studio 2005
C# 3.0 with Visual Studio 2008，2010（.net 2.0, 3.0, 3.5）
C# 4.0 with Visual Studio 2010（.net 4）
C# 5.0 with Visual Studio 2012（.net 4.5），2013（.net 4.5.1, 4.5.2）
C# 6.0 with Visual Studio 2015（.net 4.6, 4.6.1, 4.6.2）
C# 7.0 with Visual Studio 2017（.net 4.6.2, 4.7）
C#版本是VS版本決定的，也可與相應的.net framework版本對應起來）
C# 版本 7
讓我們從元組 (tuple) 開始。首先這裡我有一個完整的程式。然後裡面有一些數字值。因為數字是非常容易理解的，但是可能不是所有人都能夠知曉其中的含義：我們現在擁有的是二進位的字面量。這是一個很微小的特性。當您教孩子編程的時候，這就非常有用了，這些位於數字下方的則是位 (bit)。我現在要再添加一個。我們這裡同樣還有數字分隔符，就像其他語言所做的那樣，您可以將這些分隔符放在需要的地方，從而讓數字更容易閱讀。
我這裡打算實現一個名為 Tally（計數器） 的方法，它將數組當中的數字累加起來，得出計算結果。這樣我們便可以對這些數字調用這個 Tally 方法。當然目前這個方法我還沒有實現，讓我們使用重構來生成這個方法。這是一個靜態方法。目前它的返回值為 Void。或許它應該返回其他的東西。我覺得它應該要返回這個累加值，或者直接返回數字的總數？我覺得兩者都是非常重要的。但是現在在 C# 當中您只能返回一樣東西，但是在不久的將來，您就可以返回兩個返回值了，甚至三個、四個、更多。只要您想，您實際上可以創建一個超大的元組，但是這可能是個糟糕的主意。
現在讓我們返回兩個 int 值。這是一個元組類型。它表示裡面有兩個 int 類型，這應該很容易理解。這裡是元組字面量，我們還是先返回一些虛擬的值。這裡麵包含了一些所需的值，通過括弧和逗號包裹起來，當然這個語法應該比較正常。當我使用這個方法的時候，我可以獲取它的返回值，然後我會發現我得到了一個元組類型。
那麼我們該如何使用元組呢？讓我們將其輸出出來。插入字元串。總和可能位於這裡的第一個位置。讓我們來看一下元組有些什麼：Item1 和 Item2。很顯然，我們知道它們分別代表了什麼，我們可以直接使用這兩個名稱。雖然這個名字比較糟糕，但是能用就行。C# 當中的元組還可以為不同的元素賦予不同的名稱。這裡我將指定各個元素的名稱。這是什麼意思呢？
當我獲取到這個元組的時候，它便可以告訴我它裡面的元素是什麼。這同樣也意味著我來到這裡，輸入點語法，就可以看到這些預覽而已；最終的版本應該需要隱藏掉這些糟糕的名字。這裡我們會看到擁有了很顯然的名字，因為這裡您可以看到 sum，我們可以直接使用它來獲取元組當中對應的值。之前那些是底層當中的真實名稱，但是編譯器知道跟蹤這些別名，並使用它們來替代顯示。
元組當中擁有元素別名是非常重要的，因為您很可能記不住這個元組是姓在前還是名在前。因此元組需要提供這些信息，這樣才能夠讓人容易理解。您需要有獲取別名的能力。
當然，您很可能會希望在獲取到元組的時候，就立刻將其解構，將元組當中的值分開，當然您也可以在 C# 當中做到這一點。您可以在這裡聲明 sum, count，然後元組便會立刻解構為 sum 變數和 count 變數。這樣我們便可以不再使用 t. 首碼，而是直接使用 sum 和 count。
讓我們現在來實現這個方法。這裡我們不再返回一個虛擬值，讓我們返回一個真實的結果。這裡我們對這些數字執行 foreach 操作；這裡我們將其稱為 values。接下來我們在每次遍歷的時候更新結果值。
result 這個名字太長了，我想將其命名為 r。讓我們聲明 r = 這個新的元組字面量。這裡我希望能夠獲取舊有的值。我希望 r 同樣也有元素別名。讓我們前去給其增加別名。您可以在元組字面量當中為其賦別名。這裡的語法和命名參數所做的相同。現在 r 擁有了 s 和 c 兩個元素別名。我們可以調用 r.s，便可以在這裡獲取到之前的總和值，然後加上新的值 v，然後這裡的 r.c 總數需要加 1。
&nbs
