In looking at how hashing was implemented, I noticed that the use of the std io::Write trait introduced quite a bit of fallibility that didn't seem necessary for most uses at least within the crate (in particular, theDigest trait's update() method that is being called by the io::Write wrapper don't fail -- neither does Vec::extend()). The fallibility then requires odd workarounds such as the unwrap_or_default() calls on hash output. In this case it seemed better to me to introduce a custom Writer trait with an infallible write() method. Since most calls don't need the length of the written slice, I added a default method implementation wrapper that does the length tracking which is used where needed.
I'm still not fully clear on which parts of this are public API; if you have a need for callers that want to write into actually fallible io::Write implementations directly I suppose this doesn't fly, but I feel like there will probably always be a layer of buffering in between.
mdecimus
commented
1 year ago
In looking at how hashing was implemented, I noticed that the use of the std
io::Writetrait introduced quite a bit of fallibility that didn't seem necessary for most uses at least within the crate (in particular, theDigesttrait'supdate()method that is being called by theio::Writewrapper don't fail -- neither doesVec::extend()). The fallibility then requires odd workarounds such as theunwrap_or_default()calls on hash output. In this case it seemed better to me to introduce a customWritertrait with an infalliblewrite()method. Since most calls don't need the length of the written slice, I added a default method implementation wrapper that does the length tracking which is used where needed.I'm still not fully clear on which parts of this are public API; if you have a need for callers that want to write into actually fallible
io::Writeimplementations directly I suppose this doesn't fly, but I feel like there will probably always be a layer of buffering in between.