Added hexadecimal encoding module

[sfackler]

FromHex ignores whitespace and parses either upper or lower case hex
digits. ToHex outputs lower case hex digits with no whitespace. Unlike
ToBase64, ToHex doesn't allow you to configure the output format. I
don't feel that it's super useful in this case.

[alexcrichton]

base64 typo

[alexcrichton]

Overall I think this is fine to include, although we're starting to get a fair number of encodings into libextra. I think that go's organization is nice with an encoding super-package, so perhaps we want to start moving things into:

• encoding/json
• encoding/base64
• encoding/hex

And then all future encodings can be thrown into there as well. Another thing which I think would be nice is to have a unifying trait for encoding/decoding things to/from types. I'm not quite sure how that would look, but it'd be a shame if we had different traits for all the encodings. One possible route would be for things like json/xml to implement the serialize::{Encoder, Decoder} and for things like base64/base32/hex to only convert between bytes and strings.

Regardless, I think that we should get another opinion on whether this should be included in libextra (I'm in favor), and if there's any sort of reorganization of encodings it should happen on the mailing list/issue list and not here.

[sfackler]

+1 on an encoding super-package. I think the root extra package needs to be reorganized in general.

I don't think there's a reasonable trait for base64, hex, etc to share. What would the signature be?

[sfackler]

I did notice some very weird performance numbers from hex and base64 benchmarks. The From{Base64,Hex} benchmark runs at about 2-3x the speed of the To{Base64,Hex} test even though the logic to convert from is significantly more complex and they should be touching the same amount of memory.

test base64::test::from_base64 ... bench: 1000 ns/iter (+/- 349) = 204 MB/s
test base64::test::to_base64 ... bench: 2390 ns/iter (+/- 1130) = 63 MB/s
...
test hex::tests::bench_from_hex ... bench: 884 ns/iter (+/- 220) = 341 MB/s
test hex::tests::bench_to_hex ... bench: 2453 ns/iter (+/- 919) = 61 MB/s

[bluss]

Regarding the speed of to_hex, you can do something like the following

// can't use bytes!() here
static HEXDIGITS: [u8, ..16] = [48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 97, 98, 99, 100, 101, 102];

fn to_hex_C(&self) -> ~str {
    let mut v = vec::with_capacity(self.len() * 2);
    for &byte in self.iter() {
        v.push(HEXDIGITS[byte >> 4]);
        v.push(HEXDIGITS[byte & 0xf]);
    }
    unsafe {
        str::raw::from_bytes_owned(v)
    }
}

I tested some different options and this was 3x faster than the original using .push_char (which is complex). Maybe the unsafe call to str::raw::from_bytes_owned is overkill, but it can be used since you know you output valid UTF-8.

[huonw]

I don't have a compiler to check, but why can't one use bytes!?

[sfackler]

bytes! works fine, you just have to change the type to &'static [u8]. Pushing the change in a couple of minutes.

[alexcrichton]

I was thinking about this earlier today, and currently you provide a ToStr implementation for &str and &[u8]. In my opinion, these encodings are strictly bytes on one side, strings on the other. I think it would be best to not intermingle the two of them. If someone wants to hex-encode their valid str type, I think it's better to be clearer and add the as_bytes method (which is a no-op essentially).

[sfackler]

Sounds reasonable to me. I only had a ToHex implementation for &str since ToBase64 had one. I'll yank them both. Do you think the From{Hex,Base64} implementation for &[u8] should go too? I'm leaning towards yes.

[alexcrichton]

@sfackler: yes

[omasanori]

@alexcrichton I'm prefer to distinguish serializers (JSON, ASN.1, etc.) from codecs (Base64, quoted-printable, etc.)
The names serialize::{Encoder, Decoder} is not so good IMHO. (Serialize(r) and Deserialize(r) better?)

[alexcrichton]

@omasanori, that's a good point! Let's move discussion to #8310

@sfackler, this looks good to me, I would be willing to r+ it, but again someone else should probably chime in about whether we should start shoving lots of encoding formats into libextra

[sfackler]

@brson retry?