On 04/25/2013 07:12 AM, Daniel Micay wrote:
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.
Are the only possible `close` errors related to flushing buffers?
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.
I'm assuming that, if we have `close`, then we would still make the
destructors close the stream. The point about catch though reminds me
that, given the error handling strategy we're using to catch a close
error you would still need to write:
do io_error::cond.trap(|err| {
printfln!(err);
}).in {
file.close();
}
Which could as easily be done by moving the file:
do io_error::cond.trap(|err| {
printfln!(err);
}).in {
let _ = file;
}
Both require trapping something.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
