为什么在 Rust 中元组格式限制为 12 项？答案

【问题标题】：Why is tuple formatting limited to 12 items in Rust?为什么在 Rust 中元组格式限制为 12 项？
【发布时间】：2018-08-14 16:51:55
【问题描述】：

我刚开始tutorial in Rust，我无法理解元组打印的限制：

fn main() {
    // Tuple definition
    let short = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11);
    let long = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);

    println!("{:?}", short); // Works fine
    println!("{:?}", long);  // ({integer}...{integer})` cannot be formatted using `:?` because it doesn't implement `std::fmt::Debug`
}

在我无知的观点中，可以通过迭代整个元组来轻松实现打印——这将允许在没有大小限制的情况下显示。如果解决方案如此简单，它会被实施，我在这里缺少什么？

【问题讨论】：

另见How to iterate or map over tuples?
请注意，至少对我来说，12 个元素的元组没有任何意义。

标签： printing rust tuples

【解决方案1】：

目前使用macro that only works up to 12 elements 实现打印元组。

已提出静态迭代/操作元组的功能，但已被推迟（参见例如this RFC）。对这些的实现有一些担忧（例如，您希望能够获得元组的头部和尾部，但实际上不能保证元组将按照您指定的顺序存储，因为允许编译器针对空间进行优化，这意味着获取尾部并不是一项简单的操作。

至于为什么需要特殊支持，请考虑以下元组：

let mixed = (42, true, 3.14, "foo");

如果它的所有元素都有不同的类型，你将如何迭代这个元组？这不能简单地使用常规迭代器和for 循环来完成。您将需要一些新的类型级语法，而 Rust 当前缺少这些语法。

【讨论】：

嗯，是的，这是有道理的。我仍然觉得混合情况可以解决。但我想这样做的压力还不够大。
是的，很可能关于实现的缺点和顾虑太重要而没有什么好处（大元组很少见，使用宏可以很容易地处理小元组）。请注意，大数组确实会遇到同样的问题并且更为常见，但正如@Tim 所提到的，const 泛型应该解决它们的问题。
@mcarton：我不确定这只是利益/缺点的问题，因为它是时间问题。在设置优先级时，const 泛型和可变参数泛型被推迟，以支持更紧迫的问题：特别是 NLL 和异步。 Const generics 已经计划在今年年底之前看到一些工作（已经进行了内部重构以准备地形），我相信在某些时候也将处理可变参数泛型......但是有现在改进元组的压力很小，而且需要时间才能正确地做到这一点。
@MatthieuM。当然，但是“我们没有时间定义/实现功能 X”也是“功能 X”的一个缺点。例如，NLL 也需要一段时间才能达到现在的水平，我们可以说“我们没有时间”，但它们的好处足够大，实际上已经分配了时间。
@mcarton：哦，当然。肯定有优先顺序。我的观点更多的是该功能并没有被彻底拒绝。只是它被认为是一个很大的功能，需要时间和精力才能做到正确，并且没有太多可用的功能，因为其他功能被认为更紧迫。有趣的是，如果语言不支持将元组作为内置类型，可变参数泛型可能会更优先:)

【解决方案2】：

Debug 仅在最多 12 个元素的元组上为 implemented。这就是为什么打印short 有效，但long 失败的原因。

【讨论】：

AFAIK，元组和 const 泛型之间没有关系。 const 泛型可以允许例如。在任意大小的数组而非元组上实现Debug，因为它们仍然不提供表示任意大小的元组和访问任意索引的语法。
您指向的 RFC 甚至不包含“元组”一词。我认为 const 泛型可以作为它的基础，但绝对不够。
数组的类型可以通过其元素类型和长度的组合来精确确定。元组不是这种情况，因为每个元素都可以有不同的类型。描述“所有元组”需要一些非常花哨的新类型级语法。
@mcarton 删除了 RFC 部分。将其与数组混淆。谢谢指出！