为什么C 4.0的一个元组中只有七个元素,而第八个元素是另一个元组?

我们考虑为元组添加一种句法糖分。我认为每个人都同意这是一个很好的功能,但它根本不符合预算。

似乎不太可能有人将C语言的特性应用到适当的级别,需要一个包含7个以上元素的元组,特别是考虑到现有和已建立的问题解决技术以及C语言主要面向对象的解决方案开发方法。

另一方面,F是一种主要功能性语言。因此,它以一种主要的功能性方式来做事情,并且语言特性集中在这个主要概念上。结果,使用f比使用c更有意义地使用提供您请求的语言功能所需的资源。

记住 all new language features start with 100 points against them . :)

下面是Matt Ellis关于基类库(BCL)团队的一篇很好的msdn文章,它详细介绍了他们在这方面的想法以及有关 Tuple 类。

建筑元组: http://msdn.microsoft.com/en-us/magazine/dd942829.aspx

由于.NET泛型的设计,泛型类型参数的数目在编译时是固定的。因此,他们必须选择一些通用参数来实现。文章解释说它是在现有的 Action 和 Func 代表。具有讽刺意味的是, 行动 和 芬克 随后添加了最多16个泛型类型参数,但是 元组 开发商并没有效仿。

这是我的猜测,但我怀疑另一个因素是f有一个相当复杂的机制来存储特定于语言的元数据。需要有某种方法来区分“最后一个元素是3元组的7元组”和9元组,即使它们在.NET类型方面以相同的方式编码。F通过自定义元数据块来实现这一点,就像它使用元数据来存储比内置到.NET中的约束(例如枚举或成员约束)更具表现力的约束一样。C没有使用程序集存储复杂的特定于语言的元数据的历史记录,其中某些形式将是处理扩展元组的必要先决条件(尽管在这种情况下,自定义属性可能足够)。

好吧,你问题的简单答案是C没有提供 任何 使用元组时的句法糖分,因此当有8个以上的元素时,无法隐藏元组的嵌套。

当然,我猜你是在问为什么在C 4.0中使用元组没有语法上的优势。我认为它不存在的主要原因是它鼓励轻量级的编程风格,而C通常不支持这种风格(但对于F程序员来说效果很好)。

• 在f中,编写这样的代码非常好:

  let parseRecord rc = 
    // some code to parse the argument
  let (left, top, wid, hgt, str) = parseRecord record
  

  但是,只有在开发过程的早期阶段(编写原型和试验时),或者功能非常本地化(在一个函数中使用),此代码才是合理的。在代码的更高级的版本中,您可能会用一些更合适的数据结构(例如f record)替换它,以使代码更可读,我认为这就是人们 典型地 在F中做

• 另一方面,如果C programmer编写了类似于以下代码的代码,人们会非常害怕代码是多么不可读:

  { int, int, int, int, string } ParseRecord(string record) { 
     // some code to parse the argument
  }
  var (left, top, wid, hgt, str) = ParseRecord(record);
  

  因此,我认为C语言的总体编程风格不太适合作为元组的轻量级特性和元组上的模式匹配,因为它与其他语言的编程风格不太一样。

当然,在C中可能有更好的方法来支持这一点,并且将来可能会添加它,但是我认为此功能的集成比F中更复杂。也, 匿名类型 与元组的作用类似(但仅限于本地),因此在某些情况下,在C中并不真正需要元组。