Skip to content

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

Closed
zwarich opened this issue Jul 17, 2014 · 6 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@zwarich
Copy link

zwarich commented Jul 17, 2014

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.

@zwarich
Copy link
Author

zwarich commented Jul 17, 2014

CC: @larsbergstrom @pcwalton

@pcwalton
Copy link
Contributor

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.

@pcwalton pcwalton reopened this Jul 17, 2014
@pcwalton
Copy link
Contributor

Oops, hit wrong button.

@bluss
Copy link
Member

bluss commented Jul 17, 2014

Quite an esoteric feature as an addon to the more general issue of Supporting Integer parameters in generics

@Gankra
Copy link
Contributor

Gankra commented Aug 15, 2014

CC me

@rust-highfive
Copy link
Contributor

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
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

7 participants