In this PR we're doing several breaking changes:

• move all detailed implementations tostd/util/math
• make all Math's methods polymorphic
• remove non-standardNativeMath#scalebn
• remove non-standardNativeMath#rem
• remove non-standardNativeMath#mod (but not tests)
• removeNativeMathf completely
• for now, we have only singleMath.random (forf64 type)

Caveats:

1. I have observed quite often the script that users from JS for example:

functionfoo(x:i32,y:i32):i32{letres=Math.floor(x/y)asi32;returnres;}

Before this PR this will create unnecessary cast to f64,Math.floor and downcast toi32. With this PR this code now equivalent tox / y without all this unnecessary work due toMath.floor,Math.trunc and etc accept integers and pass through it "as is".

2. Now following code will generate a compilation error:

constcos3=Math.cos(3);// -> ERROR: Math.cos accept only f32 or f64 types// Solution: it may be fixed as Math.cos(3.0)constx:i32=123;constsqr=Math.sqrt(x);// -> ERROR: Math.sqrt accept only f32 or f64 types// Solution: Math.sqrt(x as f64)

This is the most painful caveat, which can lead to many breaking changes in some code.
Perhaps we could add new generic builtin helper which forces parameter type to float. Something like:

// builtin will be equivalent to this:typeOnlyFloat<T>=Textendsf32|f64 ?T :f64functionsqrt<Textendsi32|i64|f32|f64>(x:T):OnlyFloat<T>{if(isInteger<T>()){returnbuiltin_sqrt<f64>(xasf64)asOnlyFloat<T>;}if(isFloat<T>()){returnbuiltin_sqrt<T>(x)asOnlyFloat<T>;}}// now we can use integer inputs which will forced to f64 for outputs but safely preserve f32constsqrt3=sqrt(3);// infer as sqrt<i32>(x) -> f64

Thoughts?

• I've read the contributing guidelines
• I've added my name and email to the NOTICE file