虛虛實實，亦假亦真的 ValueTuple，絕對能眩暈你

一：背景

1. 講故事

前幾天在寫一個api接口，須要對衣物表進行分頁查詢，查詢的output須要返回兩個信息，一個是 totalCount,一個是 clothesList,在之前我可能須要封裝一個 PagedClothes 類，以下代碼:

public class PagedClothes
    {
        public int TotalCount { get; set; }
        public List<Clothes> ClothesList { get; set; }
    }

    static PagedClothes GetPageList()
    {
        return new PagedClothes()
        {
            TotalCount = 100,
            ClothesList = new List<Clothes>() { }
        };
    }

在 C# 7.0 以後若是以爲封裝一個類太麻煩或者沒這個必要，能夠用快餐寫法，以下代碼：

static (int, List<Clothes>) GetPageList()
    {
        return (10, new List<Clothes>() { });
    }

這裏的 (int, List<Clothes>) 是什麼意思呢？ 懂的朋友看到 (x,y) 立刻就會想到它是 .NET 引入的一個新類：ValueTuple，接下來的問題就是真的是ValueTuple嗎？ 用ILSpy 看看 IL 代碼：

.method private hidebysig static 
        valuetype [System.Runtime]System.ValueTuple`2<int32, class [System.Collections]System.Collections.Generic.List`1<class ConsoleApp2.Clothes>> GetPageList () cil managed 
    {
        IL_0000: nop
        IL_0001: ldc.i4.s 10
        IL_0003: newobj instance void class [System.Collections]System.Collections.Generic.List`1<class ConsoleApp2.Clothes>::.ctor()
        IL_0008: newobj instance void valuetype [System.Runtime]System.ValueTuple`2<int32, class [System.Collections]System.Collections.Generic.List`1<class ConsoleApp2.Clothes>>::.ctor(!0, !1)
        IL_000d: stloc.0
        IL_000e: br.s IL_0010

        IL_0010: ldloc.0
        IL_0011: ret
    } // end of method Program::GetPageList

從 GetPageList 方法的 IL 代碼能夠很容易的看出方法返回值和return處都有 System.ValueTuple 標記，<font color="red">今後之後你可能就會覺得 (x,y) 就是 ValueTuple 的化身 </font>，是吧，問題就出如今這裏，這個經驗靠譜嗎？

二：(x,y) 真的是 ValueTuple 的化身嗎

爲了去驗證這個經驗是否靠譜，我須要舉幾個例子：

1. (x,y) 接收方法返回值時是 ValueTuple 嗎

爲了更加清楚的表述，先上代碼：

(int totalCount, List<Clothes> orders) = GetPageList();

        static (int, List<Clothes>) GetPageList()
        {
            return (10, new List<Clothes>() { });
        }

如今已經知道當 (x,y) 做爲方法返回值的時候在IL層面會被化做 ValueTuple，那 (x,y) 做爲接受返回值的時候又是什麼意思呢？ 還會和 ValueTuple 有關係嗎？ 爲了去驗證，能夠用反編譯能力弱點的 dnspy 去看看反編譯後的代碼：

從圖中能夠看出，當用 (x,y) 模式接收的時候，貌似就是實現映射賦值 或者 叫作拆解賦值,是否是有一點模糊，這個 (x,y) 貌似和 ValueTuple 有關係，又貌似和 ValueTuple 不要緊，不過不要緊，繼續看下一個例子。

2. (x,y) 在 foreach 迭代中是 ValueTuple 嗎

(x,y) 也能夠出如今 foreach 中，相信第一次看到這麼玩仍是有一點吃驚的，以下代碼：

var dict = new Dictionary<int, string>();

        foreach ((int k, string v) in dict)
        {
        }

接下來繼續用 dnspy 反編譯一下：

我去，這回就清晰了，從圖中能夠看出，我寫的 (x,y) 壓根就沒有 ValueTuple 的影子，說明在這個場景下二者並無任何關係，也就是說一樣是 (x,y) ，放在不一樣位置具備不一樣的表現形式，這就很讓人琢磨不透了， 可能有些朋友不死心，想看一下 Deconstruct 到底幹了什麼，知道的朋友應該明白這個新玩法叫作解構方法，繼續看代碼：

public readonly struct KeyValuePair<TKey, TValue>
    {
        private readonly TKey key;
        private readonly TValue value;

        public void Deconstruct(out TKey key, out TValue value)
        {
            key = Key;
            value = Value;
        }
    }

有些擡槓的朋友會發現一個規律，貌似 (x,y) 放在賦值語句的左邊都和 ValueTuple 沒有任何關係，放在右邊可能會有奇蹟發生，那究竟是不是這樣呢？ 繼續硬着頭皮舉例子唄。

3. (x,y) 放在賦值語句的右邊是 ValueTuple 嗎

public class Point
    {
        public int X { get; set; }
        public int Y { get; set; }

        public Point(int x, int y)
        {
            (X, Y) = (x, y);
        }
    }

嘿嘿，看這句: (X, Y) = (x, y) 裏的 (x,y) 是 ValueTuple 的化身嗎？ 我猜你確定是懵逼狀態，是吧，亦真亦假，虛虛實實，證據仍是繼續反編譯看唄。

我去，又是和 ValueTuple 一點關係都沒有，啥玩意嘛，亂七八糟的，莫名其妙。

三： 總結

說 (x,y) 是元組吧，放在 return 中就變成了 ValueTuple ，說 (x,y) 不是元組吧，放在其餘處還真就不是的，是否是很疑惑，爲了更加形象，在 Point 中再增長一個 Test 方法，對照一下源碼和反編譯的代碼：

//原始的：
    public class Point
    {
        public int X { get; set; }
        public int Y { get; set; }

        public Point(int x, int y)
        {
            (X, Y) = (x, y);
        }

        public (int x, int y) Test()
        {
            return (X, Y);
        }
    }

    //反編譯的：
    public class Point
    {
        public int X { get; set; }
        public int Y { get; set; }

        public Point(int x, int y)
        {
            this.X = x;
            this.Y = y;
        }

        [return: TupleElementNames(new string[]
        {
            "x",
            "y"
        })]
        public ValueTuple<int, int> Test()
        {
            return new ValueTuple<int, int>(this.X, this.Y);
        }
    }

反正我已經惱火了，就這樣吧，少用經驗推理，多用工具挖一挖，這樣才靠譜！