You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is due to the duplication of packing-related information across multiple methods. If we allow ourselves a breaking change, we could extend TreeHashType with the packing factor, and combine tree_hash_type and tree_hash_packing_factor into a single method:
This makes invalid states (like TreeHashType::Vector and a call to tree_hash_packing_factor) unrepresentable, which is great. However we still have the issue of the tree_hash_packed_encoding method. It is not well-defined for types other than Basic ones.
Perhaps the simplest option would be to make tree_hash_packed_encoding return a Result<PackedEncoding>, and error for non-basic types.
A more "techy" option would be to include some opaque struct to act as a token for unlocking the tree_hash_packed_encoding method. Something like:
/// This struct can't be constructed except by the library.pubstructPackedEncodingToken<T>{_phantom:PhantomData<T>,}pubenumTreeHashType<T>{Basic{packing_factor:usize,token:PackedEncodingToken<T>,},Vector,List,Container,}pubtraitTreeHash{fntree_hash_type() -> TreeHashType<Self>;fntree_hash_packed_encoding(&self,token:PackedEncodingToken<Self>) -> PackedEncoding;fntree_hash_root(&self) -> Hash256;}
This design prevents downstream users from calling tree_hash_packed_encoding unless they've obtained a PackedEncodingToken from calling tree_hash_type. It does not prevent library maintainers from adding incorrect implementations of tree_hash_packed_encoding, but would prevent those implementations from being reachable.
The text was updated successfully, but these errors were encountered:
I started thinking about redesigning the
TreeHash
trait while working on this PR to fix some broken implementations:FixedBytes
implementation and bug fixes #28The current trait is arguably dangerous to use, due to the prevalence of panicky methods:
tree_hash/tree_hash/src/impls.rs
Lines 219 to 230 in e9708cd
This is due to the duplication of packing-related information across multiple methods. If we allow ourselves a breaking change, we could extend
TreeHashType
with the packing factor, and combinetree_hash_type
andtree_hash_packing_factor
into a single method:This makes invalid states (like
TreeHashType::Vector
and a call totree_hash_packing_factor
) unrepresentable, which is great. However we still have the issue of thetree_hash_packed_encoding
method. It is not well-defined for types other thanBasic
ones.Perhaps the simplest option would be to make
tree_hash_packed_encoding
return aResult<PackedEncoding>
, and error for non-basic types.A more "techy" option would be to include some opaque struct to act as a token for unlocking the
tree_hash_packed_encoding
method. Something like:This design prevents downstream users from calling
tree_hash_packed_encoding
unless they've obtained aPackedEncodingToken
from callingtree_hash_type
. It does not prevent library maintainers from adding incorrect implementations oftree_hash_packed_encoding
, but would prevent those implementations from being reachable.The text was updated successfully, but these errors were encountered: