With the stabilization of const
methods new
, len
, and is_empty
for BTreeMap in 1.66.0, I'm curious about the intended use cases when we can't directly populate a const
BTreeMap at compile time.
Are there ways to populate a const
BTreeMap I'm overlooking?
Are the current const
methods primarily meant to work in conjunction with future language features?
Not sure about the others, but const new
is useful for putting a BTreeMap
in a static
:
static FOO: Mutex<BTreeMap<i32, String>> = Mutex::new(BTreeMap::new());
(since Rust doesn’t have runtime initializers for static variables).
3 Likes
The proposed future feature for populating a BTreeMap at compile time is:
opened 11:53AM - 01 Dec 20 UTC
A-allocators
T-lang
T-libs-api
C-tracking-issue
A-const-eval
needs-rfc
Libs-Tracked
S-tracking-impl-incomplete
This is a tracking issue for https://github.com/rust-lang/const-eval/issues/20
… The feature gate for the issue is `#![feature(const_heap)]`.
The general design can be found [here](https://hackmd.io/h2O2vkj3RimrBTfm9hvZWA#AllocRef-allocGlobal-and-allocConstGlobal)
### About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
### Steps
- [ ] Implement https://github.com/rust-lang/const-eval/issues/20 experimentally
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])
[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
### Unresolved Questions
* Do we want to allow the regular `Global` allocator? This would give us post-monomorpization errors. More details can be found in https://hackmd.io/h2O2vkj3RimrBTfm9hvZWA#Transient-heap-allocations-via-Global
* If we stabilize this, we fundamentally change the nature of `const fn`: before this change, a `const fn() -> T` would inevitably have to always return the same value; after this change, that is no longer the case. With `ptr_guaranteed_eq`, this can even to some extend be observed during CTFE. So in that sense, this feature is much bigger than anything we ever stabilized for CTFE.
* We can already emulate all this via `build.rs` scripts or proc macros that generate the appropriate constants/statics and references them. Const heap will "just" make generating static/const allocations more convenient.
* Once we permit references to things that (can) contain interior mutability, it would be possible for users to write a `const fn foo() -> &'static Cell<i32>`, which could then be used to initialize a `const FOO: &'static Cell<i32>` which is unsound (and only caught by dynamic checks). The tracking issue for interior mutability behind references is #80384
### Implementation history
* #79594 adds the base intrinsic for telling the miri-engine to create a virtual heap allocation
* #79664 makes sure that code outside of the const evaluator has no knowledge about heap allocations
2 Likes
system
Closed
July 4, 2024, 5:48am
4
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.