Default Argument and CHUNK_SIZE Refactor#155
Default Argument and CHUNK_SIZE Refactor#155ErikMcClure wants to merge 16 commits intojneem:mainfrom
Conversation
Persistent map
Support arbitrary chunks
Update to 2024
|
Thanks for the PR! I haven't really looked at it much yet, but the current type alias approach was chosen to minimize the need for annotations in the common case, as discussed a bit here: #90 (comment) |
|
After taking a look at #90 , it seems I reverted the behavior to the original approach done by @inker0, which adheres to how the standard library handles things and avoids breaking the macros, but does require additional type annotations in the two cases I mentioned. During my usage, I never encountered another location where additional types would actually be needed - they could always be inferred as long as it wasn't a function creating a new Vector. In fact, because I didn't use If you do end up adding |
|
I don't have very strongly held opinions on this, but
Absolutely no objection to adding default parameters to the |
|
Also: starting tomorrow I'll be AFK for a week and a half |
This PR is a large refactor and update of the library, moving it to Rust 2024, updating the rust version and updating most of the dependencies (I opted to ignore the bincode situation #146 for now, though). It also adds a persistent map and fold to the Vector, which I needed for a library, but this shouldn't impact the API.
The major change here is to get rid of the
Generic*versions of the structs and instead use default type arguments, while providing anew()function using the default type arguments andwith_*functions that provide more granular control. This mirrors how the standard library handles things. In most cases, simply replacingGenericNamewithNamewill suffice in current user code, but it does require using explicit arguments in two cases:::<_>::from_iter()and::<_>::unit().In addition, the RRB data structure and everything that depends on it (like
Vector) was changed to use a compiler-timeCHUNK_SIZEconstant. To be more consistent, this change should also be applied to the btree'sNODE_SIZE, which was previously requested (#145) but I'm not currently using the btree. This should at least give you an idea of what the consequences of moving to a const generic will be in case you have your own plans for that.This is a substantial breaking change to the library API, which would require yet another version increment - apparently the version was just updated to
7.0a few weeks ago. I don't actually know who the primary users of this library are, so I am offering this PR just in case the current maintainers are interested in any of these changes.