On Sun, Aug 11, 2013 at 6:32 PM, Tom Lee <[email protected]> wrote:
>
> On Sun, Aug 11, 2013 at 3:18 PM, Jens Nockert <[email protected]> wrote:
>>
>>
>> On 12 Aug 2013, at 00:09, Tom Lee <[email protected]> wrote:
>>
>> Anyway, this sort of confusion is exactly why I don't like for..else. But
>> then maybe I'm the only one that's confused here. :)
>>
>>
>> Obviously you were not the only one, since there was a long thread without
>> clarification.
>>
>> While I think it is reasonably clear (since I am used to it), I don't
>> think it is more clear than something like (in faux pyrust)
>>
>> let iterations = xrange(100);
>>
>> for i in iterations {
>> …
>> if converged {
>> break;
>> }
>> }
>>
>> if iterations.finished() {
>> fail!("Oh noes, it did not converge");
>> }
>>
>
> I really like this. There's no room for confusion here.
The iterator adaptors don't keep track of whether they've finished,
they only bubble up the underlying `next()` calls. The `None` will be
returned during the loop, and after that there's no way to query
whether it has finished.
For example, this is zip:
fn next(&mut self) -> Option<(A, B)> {
match (self.a.next(), self.b.next()) {
(Some(x), Some(y)) => Some((x, y)),
_ => None
}
}
There's a separate thread about this, but I don't think returning
`None` forever without side effects is a guarantee we should make.
Python does not make the guarantee, and the functions like `zip` there
will continue calling the underlying iterators.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
