0 is no necessarily EOF. E.g. it's not EOF - when you requested to read 0 bytes, which is perfectly legal - when your IO Object is in nonblocking mode (yes, that's currently not supported in Rust, but might be in Future)
And the Result<Option<int>, IoError> will only create questions when the the Err Result will be used as opposed to the None Option. I don't know if you would associate an Ok(None) with an EOF if you first-time encounter it. Therefore I think the current Err(EOF) is absolutely fine. 2014-02-04 Bill Myers <bill_my...@outlook.com>: > Are we sure that this is the correct design, as opposed to having read > return 0 for EoF or perhaps returning None with a Result<Option<int>, > IoError> return type? > > After all, EOF is unlike all other I/O errors, since it is guaranteed to > happen on all readers, and the fact that it needs to be special cased might > be an indication that the design is wrong. > > Also, in addition to "raw" eof, a partial read due to end of file causes > the same issues, so it seems that code needs to have two match conditions > to handle eof, while it would only need a single one if eof was represented > by Ok(0). > _______________________________________________ > 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
