-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rust collections should support inline capacity specified as a compile-time integer #15748
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
Labels
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
Comments
Note that I've implemented this in Servo without the type-level integer support by just macro-expanding SmallVec1, SmallVec2, SmallVec4, etc. Obviously not ideal but works in a pinch. |
Oops, hit wrong button. |
Quite an esoteric feature as an addon to the more general issue of Supporting Integer parameters in generics |
CC me |
This issue has been moved to the RFCs repo: rust-lang/rfcs#319 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Many C++ projects (including all web browser engines that I am aware of, LLVM, etc.) use their own C++ collections where collections have an inline capacity specified at compile time, e.g.
Vec<T, 4>
. This means that the collection reserves space for a fixed number of elements, and it until its capacity goes above the inline capacity it can avoid a heap allocation.Obviously, this feature requires support for type-level integers in the first place. It also increases the pressure to deal with existing ergonomic issues regarding type constructor parameters, since e.g.
HashMap
would have key, value, hasher, inline capacity, and allocator parameters.The text was updated successfully, but these errors were encountered: