Skip to content
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

Replace Range variant with built-in composite definitions #130

Merged
merged 2 commits into from
Sep 1, 2021

Conversation

ascjones
Copy link
Contributor

This now describes precisely the encoding of the two range types introduces in paritytech/parity-scale-codec#269.

The extra variant added in #124 would mean that if additional Range types were added it would have to be a breaking change.

Also Range type definitions are not general SCALE concepts, they are just another "built-in" type that we can add to the prelude - e.g. Option, Result etc.

Required for #129 to prevent possible future breaking changes.

/cc @jacogr

@ascjones ascjones requested a review from dvdplm August 31, 2021 15:39
@gui1117
Copy link
Contributor

gui1117 commented Aug 31, 2021

This makes more sense to me, range is like any other composite type which contains inner types, the logic associated to its usage doesn't need to be in the primitive of scale-info but instead just a description similar to other composite types.

Copy link
Contributor

@dvdplm dvdplm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems strictly better than my version.

@@ -271,9 +269,6 @@ pub enum TypeDef<T: Form = MetaForm> {
/// A type representing a sequence of bits.
#[codec(index = 7)]
BitSequence(TypeDefBitSequence<T>),
/// A Range type.
#[codec(index = 8)]
Range(TypeDefRange<T>),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should make TypeDef be #[non_exhaustive]?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure because all TypeDef variants need to be handled usually, a wildcard might not make sense.

@jacogr
Copy link

jacogr commented Aug 31, 2021

My vote needs to be for “much worse”, but since scale-info is not mapping to constructs, seems “sensible”, aka like Option would need to do more magic to detect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants