[rust-dev] Update on I/O progress

Brian Anderson banderson at mozilla.com
Thu Apr 25 11:41:10 PDT 2013


On 04/25/2013 05:25 AM, Nathan Myers 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?

Thanks, that's an important consideration, so we do need 'close'.


More information about the Rust-dev mailing list