Hi all,
I'm very excited to announce that rustdoc_ng now extracts and
jsonifies crates completely in their entirety. Yay! Jordi has been
doing some awesome work with the frontend, even adding a search. See
http://seld.be/rustdoc/master/index.html, for its current state.
There's still a bunch of w
You could certainly design a non-blocking IO iterator that way. My example of a
non-blocking IO iterator wasn't meant to illustrate something I'd actually
recommend you do (since the iterator protocol isn't really a great fit for
this), but rather show the flexibility of the approach.
That said
Not confused, I understand your point about for loops not caring about what
happens with additional 'next' calls.
But as a user of an iterator, I have the expectation that a for loop
exhausts the elements available from an iterator unless I return early or
break. Designing an iterator that intent
I suspect you're confused about something.
The for loop doesn't care in the slightest what an iterator does after it's
returned None. All 3 approaches work equally well as far as the for loop is
concerned.
And I'm not sure what you mean by "design Iterators that would take advantage
of the und
Of course. I think I'm reacting more to the possible use cases you
described for option 3 than the actual meaning of it. It seems like a
really bad idea to design iterators that would take advantage of the
undefined behavior, not least b/c it's unexpected and not supported by the
most pervasive c
The new for loop works with all 3 of these. Your output shows that it queried
.next() twice, and got a single Some(1) result back. Once it gets None, it
never calls .next() again, whereas the 3 behaviors stated previously are
exclusively concerned with what happens if you call .next() again afte
The new for loop already assumes #2, right?
let x = [1,2,3];
let mut it = x.iter().peek_(|x| printfln!(*x)).scan(true, |st, &x| { if *st
{ *st = false; Some(x) } else { None } });
for i in it {
printfln!("from for loop: %?", i);
}
Which produces:
&1
from for loop: 1
&2
On Sun, Aug 4, 20
There seems to be a basic assumption of ASCII identifiers. Hey, this
ain't the eighties!
Let's have us an XᴍʟHᴛᴛᴘRequest. Absolutely clear with no scope for
misunderstanding in either direction: Gᴄ; Rᴄ; Aʀᴄ; SimpleHᴛᴛᴘServer.
Monospace font support is a little poor, but I'm sure they'll fix that
Heya,
I know this is a long shot given I don't see many EU people on IRC, but
would there be anyone around Zurich or in Switzerland at all that wants
to gather up for a small Rust meetup (or we can just go have a beer)?
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
__
Your example looked like it should be correct, but I'm not going to
figure out why it's not working, because extra::net no longer exists
in the Rust development head.
Here is an example using the new runtime TCP library, which is
currently in std::rt::io::net.
Whether it compiles on Rust 0.7 or n
10 matches
Mail list logo
