-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Make entity::index
non max
#18704
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
Make entity::index
non max
#18704
Changes from all commits
e6fc08a
6d67b52
ef11fb4
88aae53
d7e955b
28584d7
20d68df
3fc8506
da0268d
1f113a8
fbd9306
3164bf2
de0b7b7
5930ada
bf28752
10a39c2
afaea98
190f43b
8ba2839
2ba14d8
f91b96d
9b2dc56
73062cb
74349dc
40e1b3d
a855e13
fd628ed
30ee589
4364558
a32912c
5bd4982
f66efff
3cf5c7d
8d482c8
79a297e
28c08f0
2cbed0b
f373597
50fe2b2
b2e4116
f360294
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,9 +17,10 @@ fn make_entity(rng: &mut impl Rng, size: usize) -> Entity { | |
let generation = 1.0 + -(1.0 - x).log2() * 2.0; | ||
|
||
// this is not reliable, but we're internal so a hack is ok | ||
let bits = ((generation as u64) << 32) | (id as u64); | ||
let id = id as u64 + 1; | ||
let bits = ((generation as u64) << 32) | id; | ||
let e = Entity::from_bits(bits); | ||
assert_eq!(e.index(), id as u32); | ||
assert_eq!(e.index(), !(id as u32)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why is there a ! here now There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good question. |
||
assert_eq!(e.generation(), generation as u32); | ||
e | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there value in using NonMax over NonZero (I can see the value of banning
u32::MAX
from being a validEntity
but that doesn't require that the missing value be there)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do
u32
, we just need to document thatu32::MAX
is invalid. We can go that route, but that means there won't be a niche in things likeTableRow
or anything. (Or at least, it would be more work to convert types, etc.)If we do
u32::NonZero
, we loose both index0
andu32::MAX
. We still need careful documentation, and we need to make sure we put a dummy value at index 0 anywhere we are using it as an index.If we do
u32::NonZero
but map it to a non max somehow, then we're effectively just reinventingNonMax
.So out of those options I went with
NonMax
here. But that's not to say we can't do otherwise. If you have strong opinions otherwise, feel free to make your case.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only called it out since the PR focused solely on wanting a niche but didn't go into why this value was chosen.
IMHO I would lean towards banning 0 as a dummy (many similar setups just use 0 as explicitly none) and either fixing the places that can't handle Max or banning it. I only say that because I think the code here to use NonMax efficiently isn't worth the trade off of preserving 0 that isn't really used.
However I don't think this set of changes is bad and so wouldn't be against this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair. We just need to put a niche in the
EntityRow
, marking one value as invalid. Then the total number of ids possible is within u32::MAX. That's the goal.So we could make 0 the niche, create dummy values for every relevant list, communicate that to users, and map 0..u32::MAX onto 1..=u32::MAX in the allocator. That would work. Pro: no op to access the index. Cons: need dummy values + extra allocation + extra math in entity allocator + invalidates some serialized data.
This pr makes the max the niche, keeping everything but the bit layout exactly the same. Pro: very simple. Cons: binary ! to access + invalidates a lot of serialized data.
It's just a trade off. If the consensus is different, I'm 100% fine with that. But at the end of the day, we just need to pick one.