safe-num support

[lemunozm]

Which part of the code is the issue addressing?

• Feature

Description

I open this issue to track the changes of safe-num repo with the intention of using into centrifuge-chain.

As an overview, the safe-num aim is to allow safe arithmetic operation checks without losing readability which means, to be as close as possible to the "normal" arithmetic style while being sure all operations are checked.

How will this affect the code base

• Better readability.
• If incorporated into centrifuge-chain, most arithmetic calculations in the pallets will use it.
  The adoption could be gradual

What are forseen obstacles or hurdles to overcome?

How to allow FixedPointNumber to use it with FixedPointOperand?

The first idea of safe-num crate was to be agnostic from the framework used. But in order to enable FixedPointNumber support, we need to implement Substrate traits for SafeNum, which can only be done in the safe-num crate because of the orphan rule.

Is a substrate feature that enables these traits implementations ok?

Pending tasks

• Saturating ops implementation for SafeNum
• Assign ops implementation for SafeNum
• Ops over generic operators for SafeNum
• Accurate Overflow/Underflow for multiplication with sign (not crucial)
• FixedPointNumber support.

[LuckyPigeon]

@lemunozm
Can I give this one a shot?

[lemunozm]

Hi @LuckyPigeon, this crate is not used (at least by this moment) in our repo. It's quite experimental, but of course, you can give it a try and test if it works for you. What we are currently using (as a less aggressive solution) is our ensure module (docs here) to manage the arithmetic issues.

Currently there is an open issue to merge this in the Substrate repo: paritytech/substrate#12754

[lemunozm]

Closed in favor of substrate method's ensure_ops