System.Tuple 類型是在.NET 4.0中引入的,但是有兩個明顯的缺點:Tuple 類型是引用類型;沒有構造函數支持。為瞭解決這些問題,C# 7 引入了新的語言功能以及新的類型(*)。 ...
System.Tuple
類型是在.NET 4.0中引入的,但是有兩個明顯的缺點:
(1) Tuple 類型是引用類型。
(2) 沒有構造函數支持。
為瞭解決這些問題,C# 7 引入了新的語言功能以及新的類型(*)。
現在,如果您需要從函數中返回兩個值的合併結果,或者把兩個值合併到一個哈希表中,可以使用System.ValueTuple
類型並使用一個精短的語法來構造它們:
// 構建元組實例
var tpl = (1, 2);
// 在字典中使用元組
var d = new Dictionary<(int x, int y), (byte a, short b)>();
// 不同名稱的元組是相容的
d.Add(tpl, (a: 3, b: 4));
// 元組值的語義
if (d.TryGetValue((1, 2), out var r))
{
// 解構元組忽略第一個元素
var (_, b) = r;
// 使用命名語法和定義名稱
Console.WriteLine($"a: {r.a}, b: {r.Item2}");
}
(*) System.ValueTuple
類型在.NET Framework 4.7中引入。但是您仍然可以在較低的框架版本中使用這個功能,這時候,您必須引用一個特殊的nuget包:System.ValueTuple。
- 元組聲明的語法與函數參數聲明相似:
(Type1 name1, Type2 name2)
。 - 元組的構造語法類似於參數構造:
(value1, optionalName: value2)
。 - 兩個元組具有相同的元素類型,但不同的名稱是相容(**):
(int a, int b) = (1, 2)
。 - 元組值的語義:
(1,2).Equals((a: 1, b: 2))
、(1,2).GetHashCode() == (1,2).GetHashCode()
返回的值均是true
。 - 元組不支持
==
和!=
。在github上有一個懸而未決的討論:“支持==和!=元組類型”。 - 元組可以被“解構”,但只能轉換成“變數聲明”,而不能“out var”或
case
語句中轉換:var (x, y) = (1,2)
- OK,(var x, int y) = (1,2)
- OK,dictionary.TryGetValue(key, out var (x, y))
- not OK,case var (x, y): break;
- not OK。 - 元組是可變的:
(int a, int b) x = (1,2); x.a++;
. - 元組元素可以通過名稱(如果提供的話)或通過通用名稱
Item1
、Item2
等來訪問。
(**) 我們馬上就會明白上面幾點。
元組名稱
缺少用戶定義的名稱導致System.Tuple
類型不常用。我們可以將System.Tuple
用作一個精減方法的實現細節,但如果我們需要傳遞它,我更喜歡使用具有描述性屬性名稱的命名類型。新元組功能很好地解決了這個問題:可以為元組元素指定名稱,而不像匿名類型,即使在不同的程式集中也可以使用這些名稱。
C#編譯器為方法簽名中使用的每個元組類型指定了一個特殊的標記TupleElementNamesAttribute
(***) :
(***)TupleElementNamesAttribute
標記非常特殊,不能在用戶代碼中直接使用。如果您嘗試使用它,編譯器會報出錯誤。
public (int a, int b) Foo1((int c, int d) a) => a;
[return: TupleElementNames(new[] { "a", "b" })]
public ValueTuple<int, int> Foo(
[TupleElementNames(new[] { "c", "d" })] ValueTuple<int, int> a)
{
return a;
}
這有助於IDE和編譯器“檢查”元素名稱,並警告錯誤地使用它們:
// 正確: 元組聲明可以跳過元素名稱
(int x, int y) tpl = (1, 2);
// 警告: 由於目標類型“(int x, int y)”指定了其他名稱或未指定名稱,因此元組元素名稱“a”被忽略。
tpl = (a:1, b:2);
// 正確 :元組解構忽略元素名稱
var (a, b) = tpl;
// x: 2, y: 1. 元組名被忽略
var (y, x) = tpl;
編譯器對繼承的成員有較強的要求:
public abstract class Base
{
public abstract (int a, int b) Foo();
public abstract (int, int) Bar();
}
public class Derived : Base
{
// 錯誤:替代繼承成員“Base.Foo()”時無法更改元組元素名稱
public override (int c, int d) Foo() => (1, 2);
// 錯誤:替代繼承成員“Base.Bar()”時無法更改元組元素名稱
public override (int a, int b) Bar() => (1, 2);
}
常規方法參數可以在重寫成員中自由更改,重寫成員中的元組元素名稱應該與基本類型中的元素名稱完全匹配。
元素名稱推斷
C# 7.1 引入了一個額外的增強功能:元素名稱推斷類似於C#為匿名類型所做的推斷。
public void NameInference(int x, int y)
{
// (int x, int y)
var tpl = (x, y);
var a = new {X = x, Y = y};
// (int X, int Y)
var tpl2 = (a.X, a.Y);
}
值語義和可變性
元組是公共欄位可變的值類型。這聽起來令人擔憂,因為我們知道可變值類型被認為是有害的。這是一個邪惡的小例子:
var x = new { Items = new List<int> { 1, 2, 3 }.GetEnumerator() };
while (x.Items.MoveNext())
{
Console.WriteLine(x.Items.Current);
}
如果運行這個代碼,您會得到一個無限迴圈。List<T>.Enumerator
是一個可變值類型,但是Items
是屬性。這意味著x.Items
在每個迴圈迭代中返回原始迭代器的副本,從而導致無限迴圈。
但是只有當數據與行為混合在一起時,可變值類型才是危險的:枚舉器擁有一個狀態(當前元素)並具有行為(通過調用MoveNext方法來推進迭代器的能力)。這種組合可能會導致問題,因為在副本上調用方法而不是在原始實例上調用方法,從而導致無效操作。下麵是一組由於值類型的隱藏副本而導致不明顯行為的示例:gist。
但可變性問題依然存在:
var tpl = (x: 1, y: 2);
var hs = new HashSet<(int x, int y)>();
hs.Add(tpl);
tpl.x++;
Console.WriteLine(hs.Contains(tpl)); // false
元組在字典中作為鍵是非常有用的,並且由於適當的值語義可以存儲在哈希表中。但是您不應該在集合的不同操作之間改變一個元組變數的狀態。
解構
雖然元組的構造函數對於元組來說非常特殊的,但是解構非常通用,並且可以與任何類型一起使用。
public static class VersionDeconstrucion
{
public static void Deconstruct(this Version v, out int major, out int minor, out int build, out int revision)
{
major = v.Major;
minor = v.Minor;
build = v.Build;
revision = v.Revision;
}
}
var version = Version.Parse("1.2.3.4");
var (major, minor, build, _) = version;
// Prints: 1.2.3
Console.WriteLine($"{major}.{minor}.{build}");
解構使用“鴨子類型(duck-typing)”的方法:如果編譯器可以找到一個方法調用Deconstruct
給定的類型 - 實例方法或擴展方法 - 類型即是可解構的。
元組別名
一旦您開始使用元組,很快就會意識到想在源代碼的多個地方“重用”一個元組類型,但這並沒有什麼問題。首先,雖然C#不支持給定類型的全局別名,不過您可以使用“using”別名指令,它會在一個文件中創建一個別名;其次,您不能將元組指定別名:
//您不能這樣做:編譯錯誤
using Point = (int x, int y);
// 但是您可以這樣做
using SetOfPoints = System.Collections.Generic.HashSet<(int x, int y)>;
github上有一個關於“使用指令中的元組類型”的討論。所以,如果您發現自己在多個地方使用一個元組類型,你有兩個選擇:保持複製粘貼或創建一個命名的類型。
命名規則
下麵是一個有趣的問題:我們應該遵循什麼命名規則來處理元組元素?Pascal規則喜歡ElementName
還是駱峰規則elementName
?一方面,元組元素應該遵循公共成員的命名規則(即PascalCase),但另一方面,元組只是包含變數的變數,變數應該遵循駱峰規則。
如果元組被用作參數或方法的返回類型使用PascalCase
規則,並且如果在函數中本地創建元組使用camelCase
規則,可以考慮使用基於用法和使用的不同命名方案。但我更喜歡總是使用camelCase
。
總結
我發現元組在日常工作中非常有用。我需要不止一個函數返回值,或者我需要把一對值放入一個哈希表,或者字典的Key非常複雜,我需要用另一個“欄位”來擴展它。
我甚至使用它們來避免與方法類似的ConcurrentDictionary.TryGetOrAdd
的閉包分配,需要額外的參數。在許多情況下,狀態也是一個元組。
該功能是非常有用的,但我還想看到一些增強功能:
- 全局別名:能夠“命名”一個元組併在整個程式集中使用它們(****)。
- 在模式匹配中解構一個元組:
out var
、case var
語法。 - 使用運算符
==
進行相等比較。
(****)我知道這些功能是有爭議的,但我認為它非常有用的。我們可以等待Record類型,但還不確定Record是值類型還是引用類型。
原文:《Dissecting the tuples in C# 7》https://blogs.msdn.microsoft.com/seteplia/2017/11/01/dissecting-the-tuples-in-c-7/
翻譯:Sweet Tang
本文地址:http://www.cnblogs.com/tdfblog/p/dissecting-the-tuples-in-c-7.html
歡迎轉載,請在明顯位置給出出處及鏈接。