-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add BitVec support #98
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally dislike the bitvec
crate for being overcomplicated but if it is used pervasively by Polkadot/Sustrate and is thereby supported by parity_scale_codec
we should also support it. Implementation looks fine to me.
src/ty/mod.rs
Outdated
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))] | ||
#[cfg_attr(any(feature = "std", feature = "decode"), derive(scale::Decode))] | ||
#[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Encode, Debug)] | ||
pub struct TypeDefBitVec<T: Form = MetaForm> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rename this to TypeDefBitSequence
to match with Sequence
type definition.
src/ty/mod.rs
Outdated
#[cfg(feature = "bit-vec")] | ||
/// A BitVec type. | ||
BitVec(TypeDefBitVec<T>), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think dtolnay mentioned that for compatibility with respect to different crate feature sets it is better to replace the inner type of BitVec
with a placeholder type (dummy) of not(feature = "bit-vec")
instead of entirely removing this variant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is much better, will avoid issues with incompatible decoding if we add variants after this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed the feature flag from this variant now so it will be binary compatible, and also so that decoding/deserializing is supported even without the feature enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you could move the bitvec stuff into it's own module (and file) to cut down on the #[cfg]
noise a bit?
Either way, lgtm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Required for
polkadot
, some types useBitVec
e.g. https://github.com/paritytech/polkadot/blob/master/primitives/src/v1/mod.rs#L468.Rationale is that
parity-scale-codec
has support for bitvec: https://github.com/paritytech/parity-scale-codec/blob/master/src/bit_vec.rs, by enabling thebit-vec
feature, so this library should too.EDIT
I've modified this so that the
TypeDefBitSequence
struct and variant is still included even withoutbit-vec
enabled, in order for compatible encoding/decoding between the crate with or without the feature enabled. Enabling the feature will simply add thebitvec
dependency and the relevantTypeInfo
impls.