C#, Scala, Haskell, Lisp and Python have the same zip behaviour: if one collection is longer, the tail is silently ignored.It could be an exception thrown as well, but I didn't heard of any language using this approach.This puzzles me. Does anyone know the reason why zip is designed that way? I guess for new languages, it is done because other languages do it this way. But what was the root reason?I am asking here factual, historic-based question, not if somebody likes it, or if it is a good or bad approach.Update: If I was asked what to do, I would say -- throw an exception, pretty similarly to indexing an array (despite old languages did all kind of magic, how to handle out of bounds index, UB, expand array, etc).
Why does 'zip' ignore the dangling tail of the collection?
design patterns
It's almost always what you want, and when it isn't, you can do the fill yourself.The main issue is with lazy semantics you don't know the length when you first start the zip, so you can't just throw an exception at the start.  You would need to first return all the common elements, then throw an exception, which wouldn't be very useful.It's also a style issue.  Imperative programmers are accustomed to manually checking boundary conditions all over the place.  Functional programmers prefer constructs that can't fail by design.  Exceptions are extremely rare.  If there's a way for a function to return a reasonable default, functional programmers will take it.  Composability is king.