C＃7值元组/解构不对称

给出一个函数(string a, string b) F()，可以解构它返回的元组：

var (a, b) = F(); 

(string c, string d) = F();

或者你可以给它分配：

var (a, b) e = F(); 

(string a, string b) f = F(); 

var g = F(); // One of these things is not like the others.

类deconstructors行为类似于第一种情况。鉴于一类C与Deconstructor(out string a, out string b)：

但是，编译器将不使用解构隐含地将其转换为一个元组：

// Cannot implicitly convert type 'C' to '(string a, string b)' 
var (a, b) l = c;

很明显，你可以写机械基础上，解构的隐式转换：

public static implicit operator (string a, string b) (C c) 
{ 
    c.Deconstruct(out string a, out string b); 
    return (a, b); 
}

尽管解构和赋值情况之间的语法在视觉上相似，但与签署对元组的引用与将类解构成变量并将它们放入新元组不同。但是，您可以将(int x, int y)隐式转换为(double x, double y)。值元组是语法糖的一种特征，它看起来就像它一样，并且不用介意实现细节。

如果我想到了这一点，C＃团队想到了这一点，如果他们选择不为隐式转换添加“魔术”支持，他们有一个很好的理由。

有一个积极的原因，为什么自动执行隐式转换会是一个坏主意？

或者它是那些被认为不足以证明成本的特征之一？

下面的代码从that fiddle：

public class Program 
{ 
    public static void Main() 
    { 
     (string a, string b) = F(); 

     (string a, string b) ab = F(); 

     Console.WriteLine($"a: {a} b: {b} ab: {ab}"); 


     var c = new C(); 

     (string d, string e) = c; 

     // Cannot implicitly convert type 'C' to '(string a, string b)' 
     (string a, string b) f = c; 

     Console.WriteLine($"d: {d} e: {e} f: {f}"); 

     // Covariance 
     (object c, object d) g = F(); 
     // Implicit conversion 
     (double x, double y) t = G(); 
    } 

    public static (string a, string b) F() 
     => ("A", "B"); 

    public static (int x, int y) G() 
     => (0, 1); 
} 

public class C 
{ 
    public String A = "A"; 
    public String B = "B"; 

    public void Deconstruct(out String a, out String b) 
    { 
     a = A; 
     b = B; 
    } 
}

C＃团队可能不会比其他人更聪明，但我从来没有赔了钱打赌，他们至少和我一样聪明。

来源

2017-05-11 Ed Plunkett

很明显，你不希望隐式解构就像你通常不希望从一个类到另一个类的隐式转换一样。而且，使用来自同一个源的元组和解构变量没有多大意义。它只会使代码更难理解。作为一个语言设计者，无论如何开始更严格，然后最终泛化，而不是相反。例如，参考类型默认为可空的事实是C＃现在被认为是最大的设计错误之一... – Phil1970