-
Notifications
You must be signed in to change notification settings - Fork 108
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
Add bytes to type reference helper methods to FromBytes
#526
Conversation
Awesome, thanks for this! Taking a look now... Do y'all actually make use of |
We don't use |
No objection to supporting both; I'm just curious what your use cases are. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! A few small nits.
I'm going to hold off on approving until we resolve the discussion in #524, and I also want to wait until some other folks have a chance to chime in who aren't working this week. I expect we can have this all resolved and merged early next week.
There are probably valid use cases for It's common for a subsystem like TPM to receive a buffer that is larger than the message it contains when the request buffer is shared for the response. |
These helper methods intend to improve the developer experience. They follow the same naming and error handling scheme as `read_from`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had another request for this, so I'm going to land it and follow up on the outstanding comments in a follow-up PR.
This has been published in 0.7.18. |
One common complaint I receive is how onerous it is to convert from bytes to type references in zerocopy for simple cases. I fully agree; we don't use the
Ref
type in most of our code.AsBytes::as_bytes
makes it easy to go from&T
to&[u8]
, so why is there such a dance to go the other way?These helper methods intend to improve the developer experience. They follow the same naming and error handling scheme as
read_from
. I would rather these stay named as such until a refactor ofread_from
andwrite_to
occurs to match - I find that consistency valuable.These avoid a tuple return in
from_[suffix|prefix]
- again for developer UX since we usually threw these out.