-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Remove uses of uint
that are not pointer-related from the Int
trait
#20211
Conversation
Use `u32` instead.
(rust_highfive has picked a reviewer for you, use r? to override) |
Strictly speaking these are actually pointer/memory related, since one could have up to (very approximately) |
@huonw: If the traits hadn't dropped support for non-primitive types it might make sense to keep it this way. It's fine either way now, since both types are guaranteed to be large enough. |
@huonw That way, we need more than |
@tbu-: That's a good point, the number of possible bits in a single object is directly tied to the number of bytes but |
You need an integer type with at least |
I broadly agree, which is why I said 'strictly'. :)
Only pointer_size + 2, I believe. |
The length of bit sets would a good location to level the double-width integer support in LLVM and compiler-rt. It supports 64-bit integers in software when there are 32-bit hardware integers (which Rust exposes via |
@huonw: Ah, right. I got missed up and added |
Maybe we should use an associated type so that primitive types don't need double wide integers to represent their bits while people using bignum can have their double wide integers? |
@retep998: Well, these traits used to have support for big integers and other arbitrary precision types but it was all changed to taking |
@thestinger I see you making the claim that the traits exclude big numbers because the methods take |
@tomjakubowski It's not possible because of other methods, e.g. |
OK, yes, that is what I was missing. Thanks. |
@tomjakubowski: It won't work because there are functions returning |
Treating everything as values only works for iterators because the adaptors don't generally do anything with the values beyond passing them to a closure or passing them along. It didn't work out for methods like |
The I also see code using bit shifts derived from a uint |
@bluss |
Again, think of how it would look like if it wasn't such a nice name
In this case, everybody would ask why one would choose |
|
@bluss |
@tbu- Thanks for doing this! Assuming that rust-lang/rfcs#544 is accepted, we're going to need to (1) establish formal guidelines for integer usage and (2) do a full sweep of std to roll them out during alpha. (This is part of the more general rollout plan.) Do you mind waiting on this PR until a conventions RFC is accepted? (I expect this to happen quickly after alpha, if not before.) |
@aturon I'm totally fine with this, and I'm happy that this is talked about seriously. |
@aturon Should I close this PR or just wait? |
@tbu- Please close for now, it helps speed bors up, and then reopen later on when the convention is clear. Thanks again! |
Use
u32
instead.