Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for num_bits_bytes stabilization #27753

Closed
aturon opened this issue Aug 12, 2015 · 14 comments
Closed

Tracking issue for num_bits_bytes stabilization #27753

aturon opened this issue Aug 12, 2015 · 14 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Aug 12, 2015

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

@aturon aturon added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Aug 12, 2015
@eddyb
Copy link
Member

eddyb commented Aug 12, 2015

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 alexcrichton added the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Aug 13, 2015
@Manishearth Manishearth removed the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Oct 2, 2015
@alexcrichton
Copy link
Member

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

@SimonSapin
Copy link
Contributor

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

@alexcrichton
Copy link
Member

🔔 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).

@alexcrichton alexcrichton added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed I-nominated labels Dec 17, 2015
@SimonSapin
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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
Copy link

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.

@tari
Copy link
Contributor

tari commented Jan 14, 2016

Could size_of be made const so it becomes usable in const contexts even after removal of BYTES? I agree that these constants are of limited utility, but a #[cfg] dance is not very nice to work with.

@eddyb
Copy link
Member

eddyb commented Jan 14, 2016

@tari It can be, but it requires more work on constants (the actual computation only depends on the pointer size and target-specific alignments).

@alexcrichton
Copy link
Member

The libs team discussed this in triage recently and the decision was to deprecate

@alexcrichton
Copy link
Member

Closed by #30943

@SimonSapin
Copy link
Contributor

This was removed without any replacement :(

@SimonSapin
Copy link
Contributor

To clarify, since the first message of this thread mentions i32, I only care about one const for the size of usize/isize/pointers, since that’s the only one that changes per platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants