-
Notifications
You must be signed in to change notification settings - Fork 356
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
Type safe bounds #627
Type safe bounds #627
Conversation
f9dcf3d
to
bc1778e
Compare
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.
lgtm
Being nitpicky as I am, I'd consider changing test names slightly. I'm not sure what exactly range2_...
means.
Initially I wanted to point out, that bound
imports in unique.rs
and multi.rs
are without cfg = iteration
mark, but then I noticed that types that uses them have those decorators in lib.rs
. Nice that you were so precise about that.
Also, iterating over prefix is neat!
Will fix those. Thanks. |
Implement bounder for primitive types
Use tuple of IK and PK for multi index bound type
0150c85
to
a3ea930
Compare
Required for `edition2021` feature
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.
Finally got to review it. Looks very nice and impressive you got this to work without much breaking APIs.
A few comments to consider
Closes #462. Implements typed range bounds, following the same approach than
PrefixBound
. Also introduces a couple raw variants, for flexibility and generality.Did all the changes in this PR, except for some refactoring, that will be published separately.
Lots of changes, but mostly cosmetic. The main impls are in keys.rs, where
Bound
was renamed toRawBound
, and a new typedBound
was introduced. All this will be moved to its ownbound.rs
module for clarity (in a follow-up).There's also a new
Bounder
trait, to build bounds from the keys (i.e.key.inclusive_bound()
syntax), but it is mostly accessory / cosmetic.Some small follow-ups / questions from here:
prefix_range
? After this new syntax for bounds,prefix_range
is a little redundant. It's still clearer than using composite keys with empty elements. So, I'm not sure here.index_key
helpers to return typed keys, or deprecate them entirely.prefix_range_raw()
impls. If we don't deprecate it, let's add these for completeness in:SnapshotMap
IndexedSnapshotMap
UniqueIndex
sub_prefix_range/_raw()
. If we don't deprecate it, let's decide if we add these or not (only really useful for triple keys).Note:
CI checks are failing due to the no-iterator variant. Solved in #629.(fixed / merged)