C＃7.2和8.0路線圖

最新 06-22

C# 7.2和8.0的許多新功能已經列入了計劃，其中包括空引用類型和有限形式的多重繼承。

只讀引用和只讀結構體 [7.2原型]

首先提到的是只讀引用和結構體。簡單來講，這項特性使得C#能夠使用類似const的參數來提高性能。像我們所知道的「ref只讀參數」和簡單的「in參數」，這些特性使得大的結構體能夠通過引用來進行傳遞，並且不允許對其進行修改。

這個提案中的一部分就是只讀結構體。開發人員將一個結構體標記為只讀之後，表示任何方法都不能對這個結構體進行修改。這會對性能有很大提升，因為它會告訴編譯器，它可以跳過通常用於防止意外修改只讀變數的複製操作。

Blittable類型 [7.2提案]

維基百科上是這樣描述blittable類型的：

在微軟的.NET框架中，數據在託管代碼和非託管代碼中的內存表示是截然不同的。然而，blittable類型被定義為在這兩種不同的環境下，數據在內存中的表示是完全相同的，並且可以直接共享。

Non-blittable類型包括Boolean、string、char以及所有的引用類型。如果一個結構體包含了其中的一種類型，那麼這個結構體本身也是non-blittable的。

目前，C#編譯器通過檢查一個類型的結構來推斷它是否是blittable的。這在過去引發了一些問題，因為有時增加一個新的欄位會使得一個blittable類型變成non-blittable，然而在某些情況下，這種變化是致命的。

在Blittable類型提案中提到，使用關鍵字「blittable」能夠明確地將一個結構體定義為blittable的。如果之後它的類型被修改為non-blittable的，編譯器就會報錯。

為了保證長期的向後兼容性，被定義為blittable的結構中只能包含同樣明確定義為blittable的結構。此外，結構中不能使用StructLayout(LayoutKind.Auto)]。它表示的是結構體在物理內存中的排列方式。Explicit layout和sequential layout都是可以使用的。

注意：能夠修改一個結構體的LayoutKind或者Pack被認為是一個突破性的改進，因為它改善了非託管代碼訪問結構體的方式。

Microsoft擔心這個特性的過渡期。低層的類庫必須採用明確的blittable類型，更高層的類庫才能使用它們。

ref-like類型編譯期安全增強 [7.2提案]

這個特性也叫做「interior pointer」或者「類ref類型（ref-like types）」。該提案允許編譯器要求只能有特定的類型出現在棧上，比如Span。其中列舉了如下幾個原因：

Span在語義上表示的是一個包含了一個引用和一個範圍的結構體（ref T data, int length）。不管它的實現是怎樣的，對這種類型的結構體的寫入操作並不是原子的。並發地對這個結構進行「撕裂（tearing）」可能會導致它的長度和數據不匹配，有可能會引起超出訪問範圍（out-of-range）和類型不安全，這最終可能會導致GC時的堆崩潰，儘管代碼看起來似乎是「安全」的。

在一些Span的實現中，它的欄位中會包含一個託管指針（managed pointer）。託管指針不支持堆對象的欄位，並且將託管指針指向放在GC堆上的代碼會在JIT（Just-in-time）期間崩潰。

Span允許引用局部堆棧幀中的數據：單獨的局部變數或者棧上分配的數組。當Span的實例的生命周期超過了引用的數據時，這會導致未定義的行為，包括類型安全違規和堆崩潰。

ref-like類型有如下幾種使用限制：

ref-like類型不能作為數組的元

ref-like類型不能用作泛型類型參數

ref-like變數不能被裝箱

ref-like類型不能作為普通的非ref-like類型的欄位

一些間接限制，例如不允許在非同步方法中使用ref-like類型，非同步方法不支持ref-like類型欄位

事實上，這意味著ref-like類型僅能被用作參數、局部變數以及某些情況下的返回值。ref-like類型能夠包含另一個ref-like類型。

所有的ref-like類型都是只讀結構體（詳見上方描述）。

像ref類型一樣，ref-like類型最終可能會成為「單賦值（single-assignment）」類型。該提案也提到了其他保障安全的方法，但是這個方法對編譯器的負擔是最小的。

C# 8.0原型