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
Presently zero is representable in NeptuneCoins, eg with NeptuneCoins::new(0) or NeptuneCoins::zero(). Some things like balances do need to represent zero, so that is good.
However other areas of the code expect non-zero values. For example when sending a transaction with native coins, each address should have a corresponding non-zero amount.
To that end, I'm thinking that we should add a NeptuneCoinsNonZero type that methods could use to be correct-by-construction. The type system (compiler) would guarantee non-zero values, so no need to validate. This is in-line with the parse, don't validate philosophy, which has two core ideas:
Use a data structure that makes illegal states unrepresentable
Push the burden of proof upward as far as possible, but no further.
Both types would share most code and be easily convertible, eg via impl From<NeptuneCoins> for NeptuneCoinsZero and impl TryFrom<NeptuneCoinsZero> for NeptuneCoins.
I plan to impl this in a PR I'm presently working on. This issue is mainly for discussion and documentation purposes.
The text was updated successfully, but these errors were encountered:
I just realized that NeptuneCoins is signed also. So I think what is really needed for the address/amount send use-case is NeptuneCoinsUnsignedNonZero.
Further consideration/review should be given to when/if it makes sense to have negative amounts in neptune-core. I don't immediately see a need for that, but I could very well be missing something.
Presently
zero
is representable inNeptuneCoins
, eg withNeptuneCoins::new(0)
orNeptuneCoins::zero()
. Some things like balances do need to represent zero, so that is good.However other areas of the code expect non-zero values. For example when sending a transaction with native coins, each address should have a corresponding non-zero amount.
To that end, I'm thinking that we should add a
NeptuneCoinsNonZero
type that methods could use to be correct-by-construction. The type system (compiler) would guarantee non-zero values, so no need to validate. This is in-line with the parse, don't validate philosophy, which has two core ideas:Both types would share most code and be easily convertible, eg via
impl From<NeptuneCoins> for NeptuneCoinsZero
andimpl TryFrom<NeptuneCoinsZero> for NeptuneCoins
.I plan to impl this in a PR I'm presently working on. This issue is mainly for discussion and documentation purposes.
The text was updated successfully, but these errors were encountered: