On Fri, Feb 14, 2014 at 12:35 AM, Daniel Micay <danielmi...@gmail.com>wrote:
> On Thu, Feb 13, 2014 at 6:33 PM, Erick Tryzelaar
> <erick.tryzel...@gmail.com> wrote:
> > On Thursday, February 13, 2014, Gábor Lehel <glaebho...@gmail.com>
> wrote:
> >>
> >>
> >>
> >> This is not strictly true.
> >>
> >> If instead of
> >>
> >> fn next(&mut self) -> Option<A>;
> >>
> >> we had something like
> >>
> >> fn next(self) -> Option<(Self, A)>;
> >>
> >> then access to exhausted iterators would be ruled out at the type level.
> >>
> >> (But it's more cumbersome to work with and is currently incompatible
> with
> >> trait objects.)
> >
> > This is an appealing option. If it is really this simple to close this
> > undefined behavior, I think we should consider it. Are there any other
> > downsides? Does it optimize down to the same code as our current
> iterators?
>
> It's certainly not as convenient and would only work if all iterators
> were marked as `NoPod`.
>
Even if it were `Pod` (i.e. copyable), the state of the old copy would be
left unchanged by the call, so I don't think this is a problem.
You could also recover the behavior of the existing `Fuse` adapter (call it
any number of times, exhaustion checked at runtime) by wrapping it in an
`Option` like so:
fn next_fused<T, Iter: Iterator<T>>(opt_iter: &mut Option<Iter>) ->
Option<T> {
opt_iter.take().and_then(|iter| {
iter.next().map(|(next_iter, result)| {
*opt_iter = Some(next_iter);
result
})
})
}
Dunno about performance. Lots of copies/moves with this scheme, so it seems
possible that it might be slower.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
