On Sun, May 5, 2013 at 6:17 PM, Andreas Rossberg <[email protected]> wrote: > On May 5, 2013, at 23:54 , Lindsey Kuper <[email protected]> wrote: >> On Sun, May 5, 2013 at 4:19 PM, Noam Yorav-Raphael <[email protected]> >> wrote: >>> I have a simple suggestion: the current implementation of zip() returns an >>> iterator which stops whenever one of the two iterators it gets stop. >>> I use zip() in python quite a bit. I always have a few lists, where the i'th >>> value in each corresponds to the same thing. I use zip in python to iterate >>> over a few of those lists in parallel. >>> >>> I think this is the usual use case. In this use case, when the two lists >>> have a different length it means that I have a bug. it seems to me that >>> Python's behavior, and current Rust behavior, is contrary to "Errors should >>> never pass silently" from the zen of Python. >>> >>> What do you think of changing this, so that zip() will fail in such a case? >>> Another iterator, say, "zipcut" can implement the current behavior if >>> needed. >> >> For what it's worth, in Wikipedia's comparison of implementations of >> zip for various languages [0], none of them raise an error when the >> lists are different lengths; they all either stop with the shorter of >> the two lists, or fill in the missing values with a nil value. > > That may be coincidence, however, since the page lists only a handful of > languages. As a counter example, OCaml, which calls it 'combine', throws. > Standard ML even provides two variants, 'zip' and 'zipEq', the latter > throwing. (And as an additional data point, nowhere in my SML code have I > ever had a need for the non-throwing version.)
Fair point. Perhaps Rust should also provide both. I like the SML names, too. Lindsey _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
