Tracking issue for `num_bits_bytes` stabilization

[aturon]

The BITS and BYTES constants for e.g. i32 are currently unstable, due to lack of clarity around:

• Should these be associated constants of the type instead?
• Is there a better way to get at these via e.g. size_of?

cc @eddyb

[eddyb]

BYTES would be directly redundant with any kind of size_of computation in constants, so I'd be against keeping it, if the latter is on the horizon.
BITS on the other hand, is indeed BYTES * 8 in all the cases we currently provide it in, but it might be more ergonomic.
Do we have (even rough) usage numbers?
Technically, anyone can implement their own trait with associated constants, so a straight-forward replacement would be available where necessary, even if std doesn't provide it and size_of still doesn't work in constant.

[alexcrichton]

We've gotten this far without these being stable, let's just axe them.

[SimonSapin]

Does this include usize::BYTES and isize::BYTES? mem::size_of doesn’t work in const contexts.

[alexcrichton]

🔔 This issue is now entering its final comment period for deprecation 🔔

although ping @rust-lang/compiler, I hear claims that there were discussions of these constants at the work week, and there may be something we're interested of!

---

@SimonSapin yeah this'd be those constants (they're unstable today anyway).

[SimonSapin]

Is there a replacement that works in const contexts (e.g. array sizes) and does not involve multiple definitions with #[cfg(target_pointer_width = "64")]?

[SimonSapin]

A single std::ptr::BYTES constant (or some other name/location) would work, although making size_of a const fn somehow would be better.

[alexcrichton]

There isn't a replacement that I currently know of, although if this is used widely throughout the nightly ecosystem we can leave them for now until there's a suitable replacement.

[andrewtj]

I've been using std::usize::BYTES in const contexts. Doing a #[cfg(target_pointer_width = …)] dance instead wouldn't be much of a hassle but a more succinct alternative would be nice.