scala - Scala 的 Map.unzip 返回的原因 (Iterable, Iterable)

Question

前几天我想知道为什么 scala.collection.Map 将其 unzip 方法定义为

def unzip [A1, A2] (implicit asPair: ((A, B)) ⇒ (A1, A2)): (Iterable[A1], Iterable[A2])

由于该方法“仅”返回一对 Iterable 而不是一对 Seq，因此不能保证原始映射中的键/值对出现在返回序列中的匹配索引处，因为 Iterable 不保证顺序的遍历。所以如果我有一个

Map((1,A), (2,B))

，然后在调用之后

Map((1,A), (2,B)) unzip

我可能会遇到

... = (List(1, 2),List(A, B))

和使用一样

... = (List(2, 1),List(B, A))

虽然我可以想象这背后与存储相关的原因(例如，想想 HashMaps)，但我想知道你们对这种行为有何看法。 Map.unzip 方法的用户可能会认为这些项目是以相同的配对顺序返回的(我敢打赌，这可能几乎总是如此)，但因为不能保证这反过来会产生难以发现的错误图书馆用户的代码。

也许应该在随附的 scaladoc 中更明确地表达这种行为？

编辑:请注意，我并不是将 map 称为 有序 集合。我只对解压缩后的“匹配”序列感兴趣，即对于 p>

val (keys, values) = someMap.unzip

它对所有 i 都成立， (keys(i), values(i)) 是原始映射的一个元素。

Answer 1

其实你给出的例子不会出现。 Map 将始终以成对的方式解压缩。您关于 Iterable 不保证顺序的说法并不完全正确。更准确地说，任何给定的 Iterable 都不必保证顺序，但这取决于实现。在 Map.unzip 的情况下，无法保证对的顺序，但对中的项目不会改变它们匹配的方式——匹配是 的基本属性 map 。您可以阅读the source到 GenericTraversableTemplate 来验证是不是这样。