-
Notifications
You must be signed in to change notification settings - Fork 35
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
Assessment of attributes #3
Comments
Ideas for attributes to add/replace: pre_assert is a bit of a hacky workaround to allow arbitrary placement of magics. It won't work nicely for a binwrite variant. Ideally, it should get replaced with something like enum MyEnum {
#[br(magic = "1u32")] X { /* ... */ },
#[br(magic = "2u32")] Y { /* ... */ },
}
struct X {
#[brw(magic_for = "data")]
magic: u32,
len: u32,
data: MyEnum
} If a magic_for attribute is present, the enum should not read the magic itself. Instead, the deserializer for X will provide it himself. |
Another addition: is essentially equivalent to |
This comment has been minimized.
This comment has been minimized.
Yep @kitlith, that's exactly what I meant by the following part of the key:
|
Ah, i missed that. |
Another addition idea: |
@jam1garner take as an attribute is a good idea that I've found myself reaching for in the past, but it's not quite that simple as the standard take adapter doesn't implement Seek (so iirc we'd run into trait constraint issues), and we probably want to allow FilePtr to (optionally?) read outside the taken area. The latter, in particular, probably causes the most issues with an adapter based approach? |
Tracking issue for figuring out how attributes will translate into the binread/binwrite merge. The main focus being which binread attributes should "just work", which can be accessible for both but not together, etc.
Key:
br
- works for binread onlybw
- works for binwrite onlybr, bw
- works for both, however a different value will need to be provided for each (example: map is a one way operation, so two maps will need to be provided to convert in both directions)brw
- works for both using a single implementation. One example could be "align", where a single alignment value would allow for both reading and writing. Would also allow for separate implementations ofbr
andbw
if desired.binread attributes
brw
questionablebrw
questionablebrw
questionableignore
Option<T> where T: BinWrite
binwrite attributes
map
write_with
, name pendingThe text was updated successfully, but these errors were encountered: