On Wed, Jun 12, 2013 at 5:21 PM, Thad Guidry <[email protected]> wrote: > Let's step back a moment... to the ORIGINAL PROBLEM that was looking for a > solution: > > " > Rust's internal iterators implement the protocol encoded in Rust's for > statement, but it's not possible to give them all a common trait or > implement > generic methods or functions taking any internal iterator. > " > > 1. Is the above really A PROBLEM ?
This is only one of many problems with internal iterators in Rust. They are very slow to compile, and often perform much worse than external iterators without hacking around the problem by forcing inlining of loop bodies (the compiler does this now) and the internal iterator itself. The closure parameter doesn't play well with regions. Almost every adaptor needs a version for `T`, `&T` and `&mut T`. Attempting to break out of a loop won't succeed if the internal iterator isn't implemented correctly. This means `break` and `return` won't always work, and won't borrow check as expected. Having the `for` body as a closure can also make dealing with local variables very painful, since uses of them are now captures. It encourages using copies instead of moves. They fundamentally cannot have their state saved, so there are many algorithms that cannot be implemented at all with them like zip, merge, intersect, union, difference, etc. Finally, there's the problem you mention of lacking the ability to encode this information in a trait, so the subset of adaptors that *can* be represented have ridiculously complex signatures and are overly complex to use. > a.) Does the solution keep dot-notation ? Internal iterators don't have a way of supporting dot notation generically in Rust. External iterator adaptors chain very well together and default methods will be a really nice way to expose them. > b.) Does the solution support no-arg iteration ? or similar ? This will be supported regardless of whether we choose internal or external iterators. It seems like a great reason to keep the current for loop syntax though. > c.) Does the solution avoid breaking tons of code ? We're already halfway done migrating away from internal iterators. The breakage has already happened and there will be more. Every single for loop is going to need to be changed yet again when `for` switches to external iterators. I think now would be the perfect time to decide if the `for` syntax should be different, although I'm totally fine with the existing syntax. > d.) Does the solution avoid adding a keyword ? The existing `for` loop can be migrated to work with external iterators. It doesn't look like we'll have any internal iterator use cases in the standard library and I think the `do` statement is enough support for third party internal iterators. Our `for` loops seem like the only reason for not currently supporting `return` in nested closures, and it would be nice to relax that restriction. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
