You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by njr0 September 27, 2023
I had a few questions/thoughts on this section.
You don't really explain what the type Item is, unless I missed it.
I wondered if you'd be able to replace the Self::Item with u32, but of course you can't.
The take(5) is obviously to prevent overflow, but I think it's more interesting without that. At least, I think you might suggest the instructor or student removes it. It doesn't take too long to run and the output is great:
I did think, however, that while this is an interesting iterator, it's a slightly weird example, being "apparently" infinite but actually only only capable of producing 46 results before overflowing. Would it be better to handle the overflow and terminate iteration when you get past the capacity of an u32? (The implementation is slightly weird too, in the it overflows one sooner than it needs to. 1,134,903,170 + 1,836,311,903 is obviously less than 4 billion (2,971,215,073) and is already stored in next.
It also feels like a slightly odd example in that .next() mutates the item in a pretty fundamental way. But maybe that's not usual? Not sure. It felt like a slightly weird example to me.
The text was updated successfully, but these errors were encountered:
I think this is a good example of an iterator that is not over a collection. Such an iterator typically will mutate itself in next (most iterators do). But, we have covered collections already, so perhaps we should make some "interesting" iterator over a Vec or something like that?
The overflow conversation is an interesting one, and sounds like a good # More to Explore section.
Discussed in #1269
Originally posted by njr0 September 27, 2023
I had a few questions/thoughts on this section.
type Item
is, unless I missed it.Self::Item
withu32
, but of course you can't.take(5)
is obviously to prevent overflow, but I think it's more interesting without that. At least, I think you might suggest the instructor or student removes it. It doesn't take too long to run and the output is great:I did think, however, that while this is an interesting iterator, it's a slightly weird example, being "apparently" infinite but actually only only capable of producing 46 results before overflowing. Would it be better to handle the overflow and terminate iteration when you get past the capacity of an u32? (The implementation is slightly weird too, in the it overflows one sooner than it needs to. 1,134,903,170 + 1,836,311,903 is obviously less than 4 billion (2,971,215,073) and is already stored in
next
.It also feels like a slightly odd example in that
.next()
mutates the item in a pretty fundamental way. But maybe that's not usual? Not sure. It felt like a slightly weird example to me.The text was updated successfully, but these errors were encountered: