jam1garner

after_parse is for parsing any non-consecutive data. for example if a FilePtr is a field in a struct, you'd want to parse the struct before parsing the data behind the...

I'd totally be willing to accept/help with/maybe work on a PR for something like this, although not sure I 100% agree with your design. First off it's pretty all or...

I'm not sure if this is a good solution for you but using an embedded struct would work for this, albeit would make member-accessing a little harder. ```rust #[derive(BinRead, Debug,...

Oh wow nice! I certainly like the work you’ve done on it, very solid looking crate. What did you have in mind? (At minimum I can certainly provide an attribute...

While in theory binread could be zero-copy for a very small subset of its features (`repr(C)` or `repr(packed)`), it would not be possible to implement currently as: 1. `BinRead` is...

@m4tx I'd accept a PR with this* as an initial implementation if you'd like :) *albeit replace unimplemented!() with an io::Error

Adding the solution since this was discussed on discord: `Vec` is inefficient due to not being special-cased the way `Vec` is (due to not matching the same type as byte...

Copied from the above commit: > Note this doesn't change the status of https://github.com/jam1garner/binrw/issues/116, however it does mitigate it. It might be worth just documenting that unit enums have less...

Tbh I'm not sure we can actually optimize this in the general case. I'm thinking the best path forward is: - For non-trivial unit enums, fall back to standard codegen...

@Holzhaus the currently recommended pattern for this is using the behavior of optionals in binrw (which is that on `None` nothing is written). so one potential option is using: ```rust...