Is there a minimal supported Rust version for this crate? It seems to require associated constants, which makes it incompatible with older Rust versions.

My understanding from the docs is that conversions via cast() should always be exact, but this is not currently the case.

let x: f32 = (!0u32).cast();
println!("{}", !0u32); // prints 4294967295
println!("{}", x); // prints 4294967300

Closes #4. I see two potential uses for these additional conversions (though didn't yet need them myself):

1. If the conversion is fallible, and failure should be handled at run-time.
2. If the conversion may be fallible and we want to ensure a check occurs (without using the always_assert feature).

~~TODO: float conversions.~~ Code share with conv is minimal and probably that's for the best.

I'll just leave this here for now. If @BartMassey or @vks or anyone else wishes to comment, please do.

Closes #9.

@vks I don't see any no_std tests for rand_distr. Maybe we should rectify that. This will still cause problems with average though, which claims to work without std.

I guess the easiest solution is to feature-gate float conversions in this crate.

I got a little fed up with it not being obvious why an assert triggered, hence this PR.

Examples:

thread 'int_casts' panicked at 'cast x: i8 to u8: expected x > 0, found x = -3'
thread 'int_casts' panicked at 'cast x: u16 to i8: expected x <= 127, found x = 256'
thread 'int_casts' panicked at 'cast x: isize to i8: expected -128 <= x <= 127, found x = 256'
thread 'float_casts' panicked at 'cast x: u32 to f32: inexact for x = 4294967295'
thread 'float_casts' panicked at 'cast x: f64 to i8 (nearest): range error for x = 127.5'

My only concern is that the extra formatting machinery may have some cost. Then again, the design of the library allows removing these "fuses" in release builds if this is deemed appropriate.

@vks thoughts?

Would be nice to provide a way to handle cast errors.

This is especially important since std::convert::TryInto() currently doesn't support conversions from integer to floating types for some reason: it would be nice to have conversions that fail if inexact.

It seems possible to make this crate work for 16-bit and 128-bit isize with a little more work. I can try to throw together a PR if desired.

I believe that Rust always requires size_of::<isize>() == size_of::<usize>(), and am pretty sure that all implementations assume that anyhow. I don't have chapter and verse on that, though.

Currently, this crate uses debug_assert_eq!() for its checks. Would be nice to provide an always crate option so that the checks are on in release mode also. I always want these checks.

The following tests failed:

Running .guix-tests/tests

running 11 tests
test float_casts ... ok
test float_trunc ... ok
test int_casts ... ok
test int_to_float ... ok
test int_to_float_inexact - should panic ... FAILED
test signed_to_unsigned ... ok
test u32_max_f32 - should panic ... FAILED
test unsigned_to_signed ... ok
test float_trunc_fail1 - should panic ... ok
test signed_to_unsigned_n1 - should panic ... ok
test unsigned_to_signed_large - should panic ... ok

failures:

---- int_to_float_inexact stdout ----
note: test did not panic as expected
---- u32_max_f32 stdout ----
note: test did not panic as expected

failures:
    int_to_float_inexact
    u32_max_f32

even though always_assert was enabled. Enabling assert_digits fixed this. I'd think that always_assert should imply assert_digits.

Currently this library is limited to basic numeric types (f*, i*, u*). Should it remain that way?

1. std::num::NonZeroU32 etc. are essentially numeric types. So should we support those?
2. What about numeric and vector types for third-party libraries, behind feature flags?
3. With a few lines of code we can support tuples ((A, B) → (C, D) where A → C, B → D, also for more elements to some limit) and arrays ([A; N] → [B; N] where A → B). It's easy to add, but may impact compile times.

Concern: casting as an operation is expected to be transitive: if a → b and b → c then a → c. Supporting additional "numeric" types such as NonZero* is therefore a substantial increase in the number of conversions we must support. (We cannot have this automatically since the type of b must be specified.)

Concern: properly casting between types from multiple third-party libraries could quickly become over-complex.

Concern: there is significant appeal in a small, minimal-dependency library.

Given the above, easy-cast will likely remain limited to standard types. Supporting arrays and small tuples may be desirable.

In 0.4.0, this panics:

f32::conv(0);

The reason: x.leading_zeros() + x.trailing_zeros() is counting every bit twice.

The easiest fix seems to be to use saturating_sub. If there's a more performant option we can switch later.

~~Unless I'm missing something, casts from float to int are currently missing. This is too bad, as these are some of the most problematic casts as provides.~~ (Edit: I was missing something. See below.) Suggested semantics are to only convert from floats that are exact integers (only zero bits after the decimal point) that will fit in the target int.

No prize for guessing what Rust does with (0.0f32 / 0.0) as u32. :slightly_smiling_face: