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
Is your feature request related to a problem? Please describe.
It would be nice to be able to add and subtract block heights. However, block heights themselves are heights, so adding and subtracting heights doesn't give a new height, it gives a difference between heights: block heights are a torsor. The ops impls we add should reflect this.
Describe the solution you'd like
We should add the following impls for block::Height:
Implementing addition/subtraction for heights themselves -- this isn't a quite correct modeling of the problem, and trying to do this probably indicates a logic error;
Adding a custom newtype for height differences -- this provides little type safety compared to using an i32, at the cost of adding and maintaining another new type, meaning additional API surface, additional impls to write, code to maintain, etc.
The text was updated successfully, but these errors were encountered:
We should add the following impls for block::Height:
I'm assuming all the i32's in these signatures are meant to represent the diffs, my preference would be to create a HeightDiff newtype to make this more clear.
Is your feature request related to a problem? Please describe.
It would be nice to be able to add and subtract block heights. However, block heights themselves are heights, so adding and subtracting heights doesn't give a new height, it gives a difference between heights: block heights are a torsor. The ops impls we add should reflect this.
Describe the solution you'd like
We should add the following impls for
block::Height
:Describe alternatives you've considered
Implementing addition/subtraction for heights themselves -- this isn't a quite correct modeling of the problem, and trying to do this probably indicates a logic error;
Adding a custom newtype for height differences -- this provides little type safety compared to using an
i32
, at the cost of adding and maintaining another new type, meaning additional API surface, additional impls to write, code to maintain, etc.The text was updated successfully, but these errors were encountered: