i128

[regexident]

No description provided.

[cuviper]

Thanks! This will be nice to have with the upcoming i128 stabilization.

You'll need to declare the feature in Cargo.toml, and test it in ci/test_full.sh for sufficiently new rustc only. Please also document the feature in README.md.

Do you plan on completing the rest of the applicable traits too? I notice at least Num, Unsigned, and cast::* remaining.

[regexident]

You'll need to declare the feature in Cargo.toml, and test it in ci/test_full.sh for sufficiently new rustc only. Please also document the feature in README.md.

Done.

Do you plan on completing the rest of the applicable traits too? I notice at least Num, Unsigned, and cast::* remaining.

• Num
• Unsigned
• cast::*

I'd prefer to leave adding i128/u128 to cast.rs to somebody more familiar with the file content's nature, tbh.

[regexident]

Any further feedback? What needs to be done to proceed? Do we want to proceed?

---

The compiler (v1.8.0) also appears to trip over the u128/i128 value suffix:

src/identities.rs:45:19: 45:24 error: invalid width 128 for integer literal
src/identities.rs:45 zero_impl!(u128, 0u128);

Any idea what to do about this? What is num-trait's stance on language backwards compatibility?

[cuviper]

What needs to be done to proceed?

I'd like to add the cast stuff -- just need to get around to it.

The compiler (v1.8.0) also appears to trip over the u128/i128 value suffix:

Does it work if you leave it as a bare 0? I think the exact type can be inferred, at least for Zero::zero(). The comparison in is_zero might have type-inference trouble still, but we can probably rewrite that as *self == $t::zero() instead.

What is num-trait's stance on language backwards compatibility?

I take a firm stance on this, which is why it's so old at 1.8 right now.

[regexident]

What needs to be done to proceed?

I'd like to add the cast stuff -- just need to get around to it.

Awesome!

The compiler (v1.8.0) also appears to trip over the u128/i128 value suffix:

Does it work if you leave it as a bare 0? I think the exact type can be inferred, at least for Zero::zero(). The comparison in is_zero might have type-inference trouble still, but we can probably rewrite that as *self == $t::zero() instead.

I removed the suffixes (from all invocations of zero_impl!/one_impl! for the sake of consistency).

The code now however (and despite being hidden behind a feature flag) fails to compile with:

error: type name `u128` is undefined or not in scope `[E0412]`

🤔

What is num-trait's stance on language backwards compatibility?

I take a firm stance on this, which is why it's so old at 1.8 right now.

👍

[cuviper]

This will need to be conditioned on TRAVIS_RUST_VERSION, so it's only attempted on Rust 1.26+ (currently just beta and nightly).

[regexident]

So remove redundant …

$run cargo build --verbose

… from rustup.sh?

And add …

if [[ "$TRAVIS_RUST_VERSION" =~ ^(nightly|beta|stable)$ ]]; then
    cargo build --verbose --features=i128
    cargo test --verbose --features=i128
fi

… to test_full.sh?

[cuviper]

rustup.sh should be harmless, but you can tweak that if you like. test_full.sh is called directly in .travis.yml -- I guess we could remove the redundant build there too. Doesn't really matter.

The condition looks fine, but I doubt stable 1.25 will work yet, as the feature was only recently stabilized for the upcoming 1.26.

[cuviper]

@regexident - I've pushed 128-bit casts, and a few other things. I'd appreciate if you could look over my changes too!

[regexident]

@cuviper looks good to me! 💪

[cuviper]

Thanks!

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[regexident]

FYI:

docs.rs failed to build num-traits-0.2.3
Please check build logs and if you believe this is docs.rs' fault, report into this issue report.

https://docs.rs/crate/num-traits/0.2.3/builds/99099

[cuviper]

Yeah. 😢 I already reported this in https://github.com/onur/docs.rs/issues/23#issuecomment-388160926