# Add Various Zip-Related Types and Operations **URL:** \ **Category:** Pitches\ **Created:** [June 18, 2018, 4:20pm UTC](https://forums.swift.org/t/add-various-zip-related-types-and-operations/13806 "2018-06-18T16:20:29Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\ **Post date:** [June 18, 2018, 10:49pm UTC](https://forums.swift.org/t/add-various-zip-related-types-and-operations/13806/9 "2018-06-18T22:49:37Z")
> [@anandabits](#): > > I don't know enough about concrete use cases to determine whether I think the eager version belongs in the standard library. That's exactly why I quoted a recent use case where an eager unzip was a win. I feel this case is common enough to justify it (and, like I say, so do other languages). And crowdsourcing these examples is kinda the point of the pitch phase. > [@anandabits](#): > > If most use cases for unzipping would benefit from laziness then including an eager version and not a lazy version in the standard library would be a disservice to users. These trade-offs are unavoidable, and worrying something _might_ be misused, even though it has legitimate uses, is a poor reason to not put it in the standard library. The policy currently in place with the std lib is: if laziness is unambiguously "free" (like `reversed()`) make it lazy by default. If there are downsides to the laziness (e.g. multiple passes would incur multiple costs – `lazy.map` is not _just_ about capturing the closure), make it eager, and if there's a lazy equivalent, put that under `.lazy`. This would be in keeping with that. --- _[View the full topic](https://forums.swift.org/t/add-various-zip-related-types-and-operations/13806)._