Re: [rust-dev] Handling I/O errors

2014-02-04 Thread Lee Braiden
On 04/02/14 03:49, Bill Myers wrote: it is guaranteed to happen on all readers I meant all finite readers, such as those for normal disk files. What are you getting at here, Bill? I thought you intended the opposite: to hint that could happen a lot on (async) infinite streams. -- Lee

Re: [rust-dev] Handling I/O errors

2014-02-04 Thread Lee Braiden
On 04/02/14 03:47, Bill Myers wrote: Are we sure that this is the correct design, as opposed to having read return 0 for EoF or perhaps returning None with a ResultOptionint, IoError return type? After all, EOF is unlike all other I/O errors, since it is guaranteed to happen on all readers,

Re: [rust-dev] Handling I/O errors

2014-02-04 Thread Armin Ronacher
Hi, Awesome. I have been waiting for this for a long time :D On 04/02/2014 02:00, Alex Crichton wrote: 2. The new if_ok!() macro. This macro has a fairly simple definition [0], and the idea is to return-early if an Err is encountered, and otherwise unwrap the Ok value. Some sample usage looks

[rust-dev] Handling I/O errors

2014-02-03 Thread Alex Crichton
Greetings Rustaceans! Upon updating your nightly builds tonight some of you may realize that all I/O code will fail to compile. Fear not, this simply means that #11946 has landed! The summary of this change is the same as its title, remove io::io_error. This is quite a far-reaching change,

Re: [rust-dev] Handling I/O errors

2014-02-03 Thread Alex Crichton
By returning a Result from all function calls, it's not much cleaner to handle errors Oops, wrong word there, I meant to indicate that it *is* much cleaner to handle errors with Result rather than conditions. ___ Rust-dev mailing list

Re: [rust-dev] Handling I/O errors

2014-02-03 Thread Bill Myers
it is guaranteed to happen on all readers I meant all finite readers, such as those for normal disk files. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev