Take my input with a grain of salt since I'm so new to the language, but here goes nothing:
> I am particularly interested in making sure that common operations are > convenient and don't require a lot of boilerplate. To that end I've been > collecting [aspirational examples] of succinctly written Rust I/O code > using the hypothetical API. The goal will be to turn these into test > cases. I welcome additional examples. One fairly common (at least to me) case I would like addressed is TCP reads/writes with timeouts. It's quite common when writing anything network related that you need to handle timeouts to be able to kill the connection and retry or abort. If you don't you easily end up with zombie processes. In the current net::tcp it seems possible using the raw socket, but not if you use any of the convenience of TcpSocketBuf. I'm not sure how this would be best implemented, but I just wanted to raise the issue before it's too late and we have to write lots of boilerplate task monitoring to have timeouts. Which is ok but a bit hard on newcomers. > ## Error handling > > I've spent a lot of time thinking about - and talking to Patrick about - > how I/O should deal with errors (the old `io` doesn't have a consistent > strategy). The [error handling strategy] I'm proposing is intended to > eliminate boilerplate and allow efficient recovery from errors, but it > uses some uncommon patterns. This seems suboptimal still. Reading your [error handling] example, I wonder if this is really better than traditional exceptions that would break the execution after the failed `new` call. Now this might not be practical to implement in rust, so I'll skip over that and assume conditions are good. You say that both `new` and `write_line` will raise a condition in this case, but that means `error` at the end contains the second condition, which probably would have a message like "could not write in a null file" or something. While the message that interests us, for debugging or printing out to the user, is the first one "could not open file because of X". I fear that in the end to be able to handle and report errors properly one would have to write so much condition handling boilerplate that simply relying on multiple return values à la Go might be best. [error handling] https://github.com/brson/rust/blob/io/src/libcore/rt/io/mod.rs#L155-164 > ## Close > > Do we need to have `close` methods or do we depend solely on RAII for > closing streams? I would say yes, because sometimes you really need to release a file to be able to do other things with it (especially on windows which likes to lock files for various reasons). > ## Constructor options > > I am considering defining `open` more like `fn open:<S: OpenSpec>(spec: > S)`, then implementing `OpenSpec` for e.g. `&str`, `Path`, `(Path, > FileFlags, FileAccess), `Url`, etc. > > Does this seem reasonable? Feels weird to have str implement something specific to another module, but if there is no other way it sounds more user friendly than a gazillion open_* methods. A few more comments on other things: - Streams are great, and the ability to register new stream protocol handler for "foo:..." urls would indeed be a big plus. - File vs FileStream, you could have a File (FileStream) and a FileInfo for the info stuff, since the latter is less commonly used. - open vs connect, I'd say open. Opening a connection sounds ok, connecting a file sounds awkward. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
