为什么“zip”忽略了这个系列的悬空尾巴？

Question

C#、Scala、Haskell、Lisp和Python具有相同的zip行为:如果一个集合更长，那么尾巴就会被忽略。

这也可能是一个异常，但我没有听说过任何使用这种方法的语言。

这让我很困惑。有人知道为什么zip是这样设计的吗？我想对于新语言来说，这是因为其他语言也是这样做的。但根本原因是什么？

我在这里问的是事实的、历史的问题，而不是有人喜欢它，或者它是好的还是坏的方法。

更新:如果有人问我该做什么，我会说--抛出一个异常，就像索引数组一样(尽管“旧”语言做了各种各样的魔术，如何处理越界索引、UB、展开数组等等)。

Answer 1

因为没有明显的方法来完成尾巴。任何关于如何做的选择都会导致一条不明显的尾巴。

诀窍是显式地延长您的最短列表，以匹配最长的长度和您期望的值。

如果zip为您这样做，您就无法知道它直观地填充了哪些值。它循环列表了吗？它是否重复了一个空值？你的类型的值是多少？

对于如何使用zip来直观地延长尾巴的方式，没有任何暗示，所以唯一合理的做法是使用可用的值，而不是编造用户可能不期望的值。

另外，请记住，您所指的是一个非常特定的、众所周知的、具有特定语义的函数。但这并不意味着你不能做一个类似但略有不同的功能。仅仅因为有一个执行x的通用函数，并不意味着您无法根据给定的目的来决定您想要做的x和y。

尽管请记住，这个函数和许多其他常见的FP样式函数是常见的，因为它们很简单，而且是广义的，所以您可以调整代码来使用它们，并得到您想要的行为。例如，在C#中，您可以只

IEnumerable<Tuple<T, U>> ZipDefaults(IEnumerable<T> first, IEnumerable<U> second)
{
    return first.Count() < second.Count()
        ? first.Concat(Enumerable.Repeat(default(T), second.Count() - first.Count())).Zip(second)
        : first.Zip(second.Concat(Enumerable.Repeat(default(U), first.Count() - second.count())))
}

或者其他简单的事情。FP方法使修改变得如此简单，因为您可以重用部分，而且实现也非常小，因此创建您自己的修改版本非常简单。