Repository navigation
Hierarchy for atomic types / precise casting? #24
Description
Thank you for a much needed crate!
We have been very successful in replacing the type hierarchy in common_traits with num-primitive and num-crates in dsi-bitstream.
We were wondering if there's in the works something like num-primitive for atomic types (or we could try to write one).
Another thing that would be nice to have is a trait for conversion without loss of precision, like in az::StrictCast or common_traits::UpcastableInto. One can convert, say, between signed and unsigned types of the same size with a bit of juggling and AsPrimitive, but I haven't found any way to write a bound implying "this can be cast into a u32 without loss of precision".
Activity
vigna commentedon Mar 7, 2026
Actually, I'll answer myself:
Into<T> + AsPrimitive<T>is equivalent tocommon_traits::UpcastableInto<T>, albeit it does not supportusize.The question remains open for atomic types.
vigna commentedon Mar 7, 2026
And I created an
atomic-primitivecreate to fill the void, replicating exactly the structure ofnum-primitive.cuviper commentedon Mar 7, 2026
Thanks for the update, and sorry I didn't reply before. I think a separate atomic crate is a reasonable outcome though!
I wonder why you need the
aspart at all for this, rather thanInto<T>alone?It also looks like the
UpcastableFrom/Intoimplementations never cross between signed/unsigned/float groups, but the primitiveFrom/Intoimplementations do. Maybe that's fine for you, and anyway I don't think I'd try to add that kind of distinction to this crate either.vigna commentedon Mar 7, 2026
I hope you don't mind if I borrowed some wording from
num-primitive. Actually, I should add a link to remark the parallelism.The problem is with
usize. The standard library has zero support. I can understand the rationale: implemented traits would vary with the pointer size.In the end, when I really had to test I used const expression blocks with an assert on the relevant
sizeof, and I have an AsU128 trait for the more structured situations.BTW, would it be possible to have ONE and ZERO as constants? I understand they are in
num-traits, but I find myself often using that crate just gfor the constants, so I reimplement them. This crate really seems their right place...
cuviper commentedon Mar 10, 2026
I'm torn, because I'm trying to keep to the principle that this crate doesn't really implement anything new, only wraps existing standard library functionality into a generic form.
AsPrimitivestrays a little from that, but at least that's still a language feature.At the same time, in my own personal projects using this crate, I also found that I really did need
ZEROandONEto get much of anything done. Maybe we can justify this (and avoid a slippery slope) by relating it toSumandProductwhich are included already, since these values are also the sum/product results with empty iterators.cuviper commentedon Mar 10, 2026
A wrinkle with the
ZEROandSumrelationship is that the standard library somewhat recently switched to-0.0for the sum of empty floating point iterators. See also rust-num/num-traits#352cuviper commentedon Mar 17, 2026
I played a bit with
ZEROandONEhere, but I fear it's a breaking change for any code that already hasConstZeroorConstOnein scope. This is "minor" being just a path ambiguity, but pretty annoying IMO.I just posted #26 as an alternative, providing
CONST: [Self: 128]for all numbers that primitives have in common. Please let me know what you think over there!vigna commentedon Mar 17, 2026
Seems great—we have ZERO and ONE anyway in a local trait, and now we can define them without macros, which is great.
One little request: any chance this can be backported to a 0.2.2 version? For a while we're stuck with Rust 1.85. I can put together a PR in case.
cuviper commentedon Mar 17, 2026
I can backport it, but it would have to follow the latest at each semver level -- i.e. 0.2.4 at 1.87 and 0.1.2 at 1.85. So the new versions would be 0.2.5 and 0.1.3, same MSRVs.
vigna commentedon Mar 17, 2026
Ok... Indeed we had to fix
=0.2.1as the MSRV was changing been minor releases, which was causing compilation to fail. We needas_to, so probably we'll be able to use CONST later.cuviper commentedon Mar 17, 2026
If you're on 2024 edition or you explicitly opt into the fallback resolver, then Cargo can figure that out for you, rather than pinning an exact version even for your dependents that could use newer. Either way, there's no room for me to insert a new
CONSTrelease in there.