Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a derive library #4

Open
porky11 opened this issue Jul 19, 2021 · 2 comments
Open

Create a derive library #4

porky11 opened this issue Jul 19, 2021 · 2 comments

Comments

@porky11
Copy link

porky11 commented Jul 19, 2021

It would be nice to be able to derive the traits TryRead and TryWrite.
It would have to be done similar to serde-derive, but will probably be a bit easier because of the simpler format used in this crate.

This will have to be done in an additional crate and will be called byte-derive.

I'll try it myself, but I'm not that experienced with proc macros.

@andylokandy
Copy link
Owner

andylokandy commented Jul 20, 2021

For simple (low-level) use cases, it usually doesn't have a common pattern like tuple, UTF-8, quotes, etc as the formats of serde have, but rather very flexible for individual protocols. Thus I think it may be hard to abstract a common way to derive the traits.

Anyway, if you've any idea about it, please share it with me 😄 .

@porky11
Copy link
Author

porky11 commented Jul 20, 2021

I don't see this problem. There don't need to be special cases for serialization of different kinds of data types.
The special case is already the implementation of the serialization traits.
The default implementation would be as simple as (de)serializing all elements of the tuple or fields of a struct in order.
And for enums, it would also add a usize for the selected variant.

But I already found another problem. You sometimes switch the context used during parsing (mostly Endian for numbers, but other types need other contexts or no context).

I'm not sure, if this is possible without increasing the complexity of this crate.
Maybe if the context was an associated type instead of a generic type of the traits, it would be easier. Currently only a single context is used for parsing most traits. But that might bring other disadvantages.

I might just try, when I really need it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants