I'm reminded of the work done at Microsoft the showed that Observable and
Enumerable were duals (e.g.
http://csl.stanford.edu/~christos/pldi2010.fit/meijer.duality.pdf )
The relevant idea is that a richer interface that includes wether the the
subject completed normally or via exception is very useful especially when it
comes to composition of such things.
as for something concrete: -1 for for-else. I don't like the reuse of 'else'
and it's not a construct most people use often.
On Aug 11, 2013, at 20:54 , Kevin Ballard <ke...@sb.org> wrote:
> For reference, in my iterative proposal, I've been considering adding a
> `.finished()` method to the Fuse adaptor, which would let you easily add that
> capability to any iterator.
>
> -Kevin Ballard
>
>> On Aug 11, 2013, at 6:47 PM, Daniel Micay <danielmi...@gmail.com> wrote:
>>
>>> On Sun, Aug 11, 2013 at 6:32 PM, Tom Lee <rust-...@tomlee.co> wrote:
>>>
>>>> On Sun, Aug 11, 2013 at 3:18 PM, Jens Nockert <j...@nockert.se> wrote:
>>>>
>>>>
>>>> On 12 Aug 2013, at 00:09, Tom Lee <rust-...@tomlee.co> 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
>> 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
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
