search

andylokandy / byte

A low-level, zero-copy, panic-free, binary serializer and deserializer. (parser and encoder)
MIT License
42 stars 7 forks source link

Usability of TryWrite trait #6

Open porky11 opened 3 years ago

porky11 commented 3 years ago

In order to use the TryWrite trait, you would need to allocate a byte array of the correct size in advance.

But how is it meant to be used? You can't know the size in advance.

I think, the API of the trait would need to change. The easiest change would be adding a second method, which returns the size in bytes without allocating anything. Another option would be to return a Result<Vec> instaed of supplying a mutable reference to an u8 slice and returning the size, but I guess, that would be inefficient. Or maybe the current trait could be used with some kind of fake slice?

So if you don't have a better solution, I'll add a new size method to the trait.

andylokandy commented 3 years ago

In order to use the TryWrite trait, you would need to allocate a byte array of the correct size in advance. But how is it meant to be used?

This crate was designed for embedded devices where allocation is not available and the buffer size is fixed at compilation. Of course, the max package size is known in advance in this case, so it wasn't a problem.

porky11 commented 3 years ago

I wanted to use it for simple conversion to binary, similar to serde bincode. I also need std and heap allocation.

Serde just seems like bloat to me, especially when just converting stuff to binary. For example when you have to implement some Deserializer yourself (which was neccessary for me because of some uncommon trait bounds), you even have to implement two different traits. And besides that, I don't like to have so many diffierent functions for serializing fields. This also should make it less efficient, if it has to read in the names of the structs, fields and enum variants, if they aren't even used.