Repository navigation
FromByteStream quite limited because only ByteRead functions can be used #14
Description
Activity
The trouble with
ByteReadbeing a subtrait ofReadis the name collision with theread()method, so that doesn't quite work.But I've pushed out a new 1.9 version with
reader_ref()andwriter_ref()methods in theByteReadandByteWritetraits to get boxed references to the underlying reader/writer which you can downcast to concrete types, if necessary. Feel free to give it a try and let me know if you find them helpful.Having a peekable reader that also implements reader methods would be a good idea, but I'll have to think of the best way to implement it.
Those don't have to be boxed. You can just return a
&mut dyn Readetc there and not have one heap allocation per call :)I'd suggest yanking 1.9.0 fast and making this change (without
Box) as 1.9.1. Technically it would be a breaking change but nobody should've depended on theBoxversion of the API yet.
Apologies if this is a bit all over the place, but just wanted to quickly drop off a note on some issues I ran into whilst trying to use
FromByteStream.The following things I sometimes need when parsing certain types of data (from a slice of bytes):
When using
ByteReaderdirectly that's no problem, since we can get access to underlying reader.However, inside a
FromByteStreamimplementation we only have theByteReadtrait to play with, which is very limited.I wonder whether it would make sense to define
ByteReadaspub trait ByteRead: Read?In addition it would also be nice to be able to
peekwithout consuming the data, but I guess that's independent.cc @sdroege