Le 19/09/2013 13:39, Jeffery Olson a écrit :
As to the implementation: rust-encoding has a lot that could be adapted. https://github.com/__lifthrasiir/rust-encoding <https://github.com/lifthrasiir/rust-encoding>Can someone comment on whether we should look at adapting what's in str::from_utf8 (really, str::raw::from_buf_len is where the action is) and str::from_utf16 for this? Everyone in IRC I ask says that they are "correct".. they're also highly optimized.. are they appropriate for this API? And if not, are comfortable having two totally separate paths for string decoding?
I don’t think anybody is advocating duplicating implementations of the same thing. My understanding is that UTF8Decoder and the existing API in std::str will end up calling the same code.
That code could be libstd’s existing implementation extended for error handling, or rust-encoding’s, or something else. I don’t have a strong opinion about it.
UTF-16 is a bit special, because libstd’s existing APIs deal with "native-endian" [u16], while encoding APIs will need both UTF-16-LE and UTF-16-BE on [u8]. I don’t know how much can be shared.
But once again, I’m more interested in getting the API and the behavior right. I trust the smart people working on Rust to refactor and optimize the implementation over time.
Cheers, -- Simon Sapin _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
