dishmaker

> Again, that can be stored in the reader type You can't store `u32` in a trait. Forcing users to implement it on their own is painful. Eg. what if...

> Otherwise, I'm not sure what other Reader impls would even make sense. GzipReader, ZlibReader, ZstdReader, ZstdPemReader, AesDeflateReader etc.. And most importantly, my: `DebugSliceReader` which tracks a lot of things...

> for the sake of argument Of course `AesDeflateReader` is my imaginery reader, but someone might want to implement it in their crate. > They accomplish two different purposes. Edit:...

I've done custom error handling for `Decode` / `DecodeValue`. It works perfectly but I had to use `std::result::Result` everywhere. Also renamed `Error` to `DerError`. ```rust /// Reader trait which reads...

Omg why are these generic Errors on a `Decode` trait :( 😢 😭 It would be a lot better on `Reader` trait. ```rust /// Reader trait which reads DER-encoded input....

> which is errors which are specific to a particular encoding format. In my opinion having generic `Reader::ERR` is a lot better. I've used it in production and such errors...

> Is there any specific way it should be done? Of course just using `Reader::ERR` would be easier. Then the entire tree of `SEQUENCE -> SET OF -> SEQUENCE ->...

> there are magic numbers you are encoding into the function's contract. I agree. The only solution i see here is naming fn `peek_up_to_8_bytes` However, for most use cases, it...

> there are magic numbers you are encoding into the function's contract. I don't see any other way to make it clearer. Such function name may seem stupid, but if...

- I think only `get_ref` is needed for now. - `.get_ref().get_ref()` pattern is common. For example in `Rc`