Type safety

[definim]

Love this library! I find my biggest concern with it is the lack of type safety.

When doing a lot of maths with decimals but converting to/from ints for things like token balances, It would be really easy to accidentally write code that treats decimals as if they are ints, and vice versa.

I am currently addressing this with extensive use of Hungarian notation, but I have considered re-writing the library for additional type safety, by defining

struct SignedDecimal59x18 {
        int256 value;
    }

and changing the library code & signatures as required so that consumers state using PRBMathSD59x18 for SignedDecimal59x18 instead of using PRBMathSD59x18 for int256.

This wold obviously be a breaking change to the library, so not something to do lightly!

I guess the biggest concern would be gas impact. I'm not sure how significant the impact would be but I'd be happy to investigate if the suggestion is of sufficient interest.

(I may end up doing this anyway for my own project; and if I do I will report back here on gas results.)

[PaulRBerg]

Hey @definim, thanks for sharing your thoughts here. After receiving the same feedback from multiple users, I decided to implement this: #36

Type safety will be added in v2.0.0.

[PaulRBerg]

I have recently released PRBMath v3.0.0, and I thought that an update here would be useful for future visitors.

Type safety is now offered via user defined value types SD59x18 and UD60x18, rather than structs (as it used to be the case in V2). The major benefit of using user defined value type rather than structs is that they do not incur any additional runtime overhead - they are a zero-cost abstraction.