On Thu, Apr 25, 2013 at 8:25 AM, Nathan Myers <[email protected]> wrote: > On 04/24/2013 03:38 PM, Brian Anderson wrote: >> >> ## String encoding >> >> I have not yet put much thought about how to deal with string encoding and >> decoding. The existing `io` module simply has Reader and Writer extension >> traits that add a number of methods like `read_str`, etc. I think this is >> the wrong approach because it doesn't allow any extra state for the >> encoding/decoding, e.g. there's no way to customize the way newline is >> handled. Probably we'll need some decorator types like `StringReader`, etc. > > > An opportunity not to be missed... since I/O objects are often > propagated through a system from top to bottom, they are an > excellent place to attach state that intermediate levels does not > need to know about. Such state traditionally includes locale-ish > formatting services, but the possibilities are much broader: time > zone, measurement-unit system, debug level, encryption/ > authentication apparatus, undo/redo log, cumulative stats, > rate and resource limits -- the list goes on. Some of these > can be standardized, and many have been, but users need to > be able to add their own on an equal basis with standard > services. > >> ## Close >> >> Do we need to have `close` methods or do we depend solely on RAII for >> closing streams? > > > close() can fail and report an error code. When you are not > interested in that, the destructor can do the job and throw > away the result, but often enough you need to know. Usually > there's not much to do about it beyond reporting the event, > but that report can be essential: did the data sent reach its > destination? If not, why not? > > Nathan Myers > [email protected] > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
You can get the errors that close would have thrown by calling flush. Closing pretty much has to be in a destructor unless you want to write finally blocks everywhere, which aren't as pretty in Rust as they are in languages which actually have that as a first-class thing. It becomes non-trivial when the lifetime isn't just based on a single scope, and can live for different periods of time. You can get deterministic destruction inside @mut with @mut Option<File> or @mut [File]. However, you already know that anything in @ will go away when the task ends, so there's already a deterministic upper-bound on the lifetime. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
