ruma / js_int Goto Github PK

From reddit:

For correctness, I must mention that the language specification will soon have a native integer type, BigInt; it’s a stage 3 proposal (see https://tc39.es/process-document/ for what that means), and Chromium has shipped an implementation.

Would be potentially useful for state-res, which since today uses an AtomicU64 in its tests and benchmarks (previously was using a static mut 😬).

cc @DevinR528

It would be good to have benchmarks that show that using Int or UInt is no slower than using i64 or u64.

(which is currently the case with the minimal-versions flag)

Rust specifies that, when debug assertions are disabled, signed integers over- and underflow. It have not found any documentation about whether bitmasks on negative integers are defined. If they are defined, this is (probably) easy to implement. Otherwise, any implementation would (probably) not be much faster than just having range-check assertions in both debug and release mode.

f64 has separate binary representations for 0 and -0. They compare equal, but the minus sign is often visible when printed the value. However, in JS converting -0 to a string results in "0". If we do add a separate binary representation, we need to ensure it compares equal and produces the same hash as 0 though.

See https://doc.rust-lang.org/std/iter/trait.Sum.html

Noticed in #11. Probably is due to std always being available with cfg(test).

Title should be self-explanatory. I think we can just go through $t64::try_from / _::try_from($t64).

Allow using Int / UInt in wasm_bindgen interfaces, if not possible yet (probably isn't)

Needs to be off-by-default since it has to delegate to std's ParseIntError::kind to be useful, and that method is unstable.

We theoretically have 54 bits of information in Int and 53 bits in UInt. Because it is much simpler to just wrap an existing numeric type, we currently use 8 bytes (64 bits) to store this data, even though 7 bytes (56 bits) would be sufficient. Implementing 7-byte storage would certainly complicate the code quite a bit and potentially affect performance negatively. I could imagine developing it out under a feature flag though. If we have benchmarks until then (#4), that would be very useful.

There is not really a reason to build serde_derive for such trivial implementations.

Currently if you have a JSON value like 42.0 it fails to deserialize to Int or UInt.

Given that a JSON encoder in a language that only supports IEEE754 doubles will not necessarily omit the fractional part like .0 it would be great to support deserializing from those as well.

This feature would be different from lax_deserialize in that it only accepts doubles that only contain an integer value, values like 0.5 would be rejected.

If there is interest in this feature I can provide a pull request.

This can either be added under the serde feature, or a new feature flag, similar to lax_deserialize.

As an example of how this could look like see:
https://github.com/communityvi/communityvi/blob/01a0beea2d95fd8256625774bfe3b6fca948e823/communityvi-server/src/utils/portable_unsigned_integer.rs#L50-L63

In particular the latest ones.

• impl TryFrom<UInt> for iN (where N < 64)
• impl TryFrom<Int> for uN (where N < 64)

Title should be self-explanatory.