Closed AloeareV closed 1 year ago
we already have
ValueSum
to represent the values of these kinds of balances.
ValueSum
is not for representing value balances; the value balance type is only ever represented abstractly in this crate. But you do raise a good point that i64
is the wrong type to use in this API.
Switching to ValueSum necessitated adding a Sub
impl... If the balance type is only ever represented abstractly, then maybe we add some safety checks and then still return an i64? Having a new type that is only ever used in the return of this one specific function is probably not the right answer either, if you can't use it anywhere without first doing a type conversion.
zcash_primitives::transaction::components::amount::Amount
is probably the right type in the abstract, but zcash_primitives
depends on orchard, so there's a circular dependency issue there
@AloeareV the type of a value balance is intentionally abstract in this crate, to allow different downstream consumers to use their own existing types (zcash_primitives::transaction::components::amount::Amount
for our crates, Zebra's own type in their case). See the documentation for the orchard::value
module, where we document this extensively.
Actually, now that I think about it, this PR should add "(and [Builder::value_balance
] for in-progress bundles)" to the end of the third bullet-point in that module documentation for orchard::value
, now that it is adding another way that value balances are produced.
Base: 88.90% // Head: 88.66% // Decreases project coverage by -0.24%
:warning:
Coverage data is based on head (
86b8afd
) compared to base (3faab98
). Patch coverage: 0.00% of modified lines in pull request are covered.:exclamation: Current head 86b8afd differs from pull request most recent head 8011e0d. Consider uploading reports for the commit 8011e0d to get more accurate results
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Once this PR lands, and is subsequently included in a release, zingolib
can unpatch orchard.
This will directly affect the development efforts of at least 3 people.
Who is eligible to review @str4d 's code? Does it need to be an ECC developer?
If @AloeareV had written the code, would it now be landed?
This was rebased onto a broken(EDIT: It wasn't rebased, but the new commit that was pushed triggered a test of this merged into the brokenmain
main
). It will need to be rebased once #358 is merged, which fixes the compilation problem (or the tests will need to be re-run manually by us).