Taking `self` would make it much harder to thread iterators statefully
through other function calls, and also make using Iterator trait objects
harder/impossible, since `next` requires `~self` until 10672 is fixed,
which is unacceptable, and mentions `Self` in the return value, making
it uncallable through something with the type erased.
Huon
On 14/02/14 21:46, Gábor Lehel wrote:
On Fri, Feb 14, 2014 at 12:35 AM, Daniel Micay <danielmi...@gmail.com
<mailto:danielmi...@gmail.com>> wrote:
On Thu, Feb 13, 2014 at 6:33 PM, Erick Tryzelaar
<erick.tryzel...@gmail.com <mailto:erick.tryzel...@gmail.com>> wrote:
> On Thursday, February 13, 2014, Gábor Lehel
<glaebho...@gmail.com <mailto: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
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
