As of now, the library does not properly serialize or deserialize unit structs, unit variants, new type structs or new type variants:

fn serialize_unit_struct(
    self,
    _: &'static str,
) -> Result<Self::Ok, Self::Error> {
    Ok(())
}

fn serialize_unit_variant(
    self,
    _: &'static str,
    _: u32,
    _: &'static str,
) -> Result<Self::Ok, Self::Error> {
    Ok(())
}

fn serialize_newtype_struct<T: ?Sized>(
    self,
    _: &'static str,
    _: &T,
) -> Result<Self::Ok, Self::Error>
where
    T: serde::Serialize,
{
    Ok(())
}

fn serialize_newtype_variant<T: ?Sized>(
    self,
    _: &'static str,
    _: u32,
    _: &'static str,
    _: &T,
) -> Result<Self::Ok, Self::Error>
where
    T: serde::Serialize,
{
    Ok(())
}

This is considered a bug and should be fixed accordingly.

I've only just remembered that rust has a special #[doc(hidden)] attribute you can use to hide items from documentation. I've added it to both the SeqEncoder and MapEncoder types and removed the note saying that these types can't be constructed outside the crate.

This does not change any behavior so I did not bump the package version.

This PR introduces encoding and decoding support for enum types and their variants.

Implementation

Consider this enum:

enum Enum {
    Unit,
    NewType(i32),
    Tuple(i32, i32),
    Struct { a: i32, b: i32 }
}

Each variant is encoded as such:

• Enum::Unit => 4:Unit.
• Enum::NewType(50) => d 7:NewType i50e e.
• Enum::Tuple(25, 50) => d 5:Tuple l i25e i50e e e
• Enum::Struct { a: 25, b: 50 } => d 6:Struct d 1:a i25e 1:b i50e e e

Note that I only added whitespace to the examples above so they are more readable.

I believe these changes are backwards-compatible, since no items were added or removed from the API. Because of this, I've bumped the package version to 0.5.4 and updated the readme accordingly.

Upon a successful merge, this PR closes #2.

This PR cleans up the unit tests for the following modules:

• de.rs
• en.rs
• lib.rs

I've added the macros test_decode, test_encode, and test_bende to each of these modules respectively, and used them to refactor repetitive testing patterns into a clearer and more readable code.

Should this be merged into the main branch, then I believe it should resolve #3.

Since there is no change in the public or private API, the version will remain the same as it is now.

I've added a couple of useful methods to the Value type. The goal of these methods is to reduce boilerplate code for library users.

I've also bumped the package version to 0.5.1 because I don't consider these additions as a breaking change.

This PR introduces a new Value type - an enum that can represent any valid bencode data type.

The en.rs and de.rs modules have been left untouched. The only change to lib.rs is that it exports the value type, and that it's docs now mention the new value type.

This is a major change so I also bumped the package version to 0.5.0.

As per #6, I've modified the MapEncoder type to sort key-value entries by key before encoding them.

First off, there are two new error types:

• KeyWithNoValue - When you try to encode a map entry's key without its respective value.
• ValueWithNoKey - When you try to encode a map entry's value without its respective key.

Then I modified the map encoder's fields, renaming the ambiguous en to encoder and adding two more fields:

pub struct MapEncoder<'a, W> {
   encoder: &'a mut Encoder<W>, // Renamed.
   entries: BTreeMap<Vec<u8>, Vec<u8>>, // Stores and sorts entries by their key upon insertion.
   current_key: Option<Vec<u8>>, // Keeps track of the current entry's key.
}

In addition to modifying the map encoder, I've also changed how KeyEncoder behaves:

Before

fn serialize_str(self, v: &str) -> Result<Self::Ok, Self::Error> {
    self.en.serialize_str(v)
}

After

fn serialize_str(self, v: &str) -> Result<Self::Ok, Self::Error> {
    self.en.write(v.as_bytes())
}

This is because we need to sort the key by their raw values before we encode them, otherwise the keys will be sorted by their length as well, which will result in this:

d
    3:zzz i0e
    4:aaaa 3:foo
e

The key zzz comes first as it is seen as 3:zzz and aaaa will come second because it starts with 4.

The other changes include:

• Changing the ordering of the encoded byte literals in tests and examples.
• I bumped the package version to 0.4.0.
• I've updated the README to reflect that you need serde as a dependency to use any of the encoding/decode methods. And I also added a note to let users know that when they encode maps and structs, their entries will be sorted first.

This is quite a change, but I doubt more changes of this magnitude will be added in the future.

As per the bencode specification, dictionaries need to be sorted by their keys in lexicographical order.

Currently, map and struct entries are encoded procedurally in the order they are given to the encoder. This of course is not how it should be done, and encoding them in an unspecified order should be and is considered incorrect behavior.

I don't believe we should introduce sorting as a cargo feature, because the bencode spec requires you to sort dictionaries before encoding them - which means it is technically a bug.

Altering the MapEncoder so that it sorts entries before encoding them will result in major changes in both the API's behavior and testing. But since map entries will always be sorted, future usage and testing of the library will be more deterministic, so it should then be considered more stable.

This is quite a drastic change, but in the long run it will definitely pay off.

An issue recently occurred to me. When encoding and decoding maps, the type of the keys is allowed to be any type. This of course is incorrect, because in bencode, dictionary keys must be of type string.

This pull request resolves this incorrect behavior by ensuring keys are of type string before encoding and decoding them.

I've added proper encoding and decoding support for unit structs (Foo) and new type structs (Foo(T)), alongside new tests.

I've also bumped the package version to 0.2.1, because #2 considers that the previous implementation should be considered a bug.

Unit variants and new type variants will only be properly implemented after we've added enum support.

There are 20 tests at the moment, but it's not nearly enough.

Here's a quick todo list:

• [ ] All the different numerical types.
• [ ] Vec<T>, &[T] and [T; N].
• [ ] HashMap, HashSet, BTreeMap, BTreeSet
• [ ] Units, tuples, tuple variants and tuple structs