ruma / js_int

JavaScript-interoperable integer types for Rust

Ruma – Your home in Matrix.

A set of Rust crates (libraries) for interacting with the Matrix chat network.

website • chat • documentation (unstable)

Getting started

If you want to build a Matrix client or bot, have a look at matrix-rust-sdk. It builds on Ruma and includes handling of state storage, end-to-end encryption and many other useful things.

For homeservers, bridges and harder-to-categorize software that works with Matrix, you're at the right place. To get started, add ruma to your dependencies:

# crates.io release
ruma = { version = "0.10.0", features = ["..."] }
# git dependency
ruma = { git = "https://github.com/ruma/ruma", branch = "main", features = ["..."] }

ruma re-exports all of the other crates, so you don't have to worry about them as a user. Check out the documentation on docs.rs (or on docs.ruma.dev if you use use the git dependency).

Status

Ruma 0.10.0 supports all events and REST endpoints of Matrix 1.10.

Various changes from in-progress or finished MSCs are also implemented, gated behind the unstable-mscXXXX (where XXXX is the MSC number) Cargo features.

A few less formalized things are gated behind the unstable-unspecified Cargo feature.

Contributing

See CONTRIBUTING.md.

Minimum Rust version

Ruma currently requires Rust 1.75. In general, we will never require beta or nightly for crates.io releases of our crates, and we will try to avoid releasing crates that depend on features that were only just stabilized.

ruma-signatures is an exception: It uses cryptographic libraries that often use relatively new features and that we don't want to use outdated versions of. It is guaranteed to work with whatever is the latest stable version though.

License

MIT

js_int's Issues

Benchmarks

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

Add usize / isize conversion implementations

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

Allow negative zero for Int?

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.

wasm_bindgen support

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

Update documentation regarding existance of a native integer type in JS

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.

Add a feature that adds a kind method to ParseIntError

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

Support deserializing from floating point without fractional component.

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

Store only 7 bytes instead of 8

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.

Add AtomicInt and AtomicUInt types

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

CI doesn't fail if special nightly tests fail

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

Stop deriving Serialize

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

How to implement signed over- / underflow for Int?

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.

Add TryFrom<f32 | f64> impls for UInt and Int

Resolve TODO comments

In particular the latest ones.

Add more TryFrom implementations

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

Implement `std::iter::Sum` for `Int`, `UInt`

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

Fix CI not catching unconditional uses of `std`

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

Can Hash implementation be improved?

Title should be self-explanatory.