# libs

**URL:** https://internals.rust-lang.org/c/libs/13.md

[Latest](https://internals.rust-lang.org/latest.md) · [Categories](https://internals.rust-lang.org/categories.md)

---

## [About the libs category](https://internals.rust-lang.org/t/about-the-libs-category/66)

<div class="topic-metadata">

**Author:** [@cmr](https://internals.rust-lang.org/u/cmr)\
**Replies:** 0\
**Last updated:** [July 12, 2014, 2:41am UTC](https://internals.rust-lang.org/t/about-the-libs-category/66 "2014-07-12T02:41:37Z")

</div>

Discussion around libraries, either in the community or officially supported (hosted by rust-lang).

---

## [\`read\_le\` and \`read\_be\` exist but \`write\_le\` and \`write\_be\` don't](https://internals.rust-lang.org/t/read-le-and-read-be-exist-but-write-le-and-write-be-dont/24707)

<div class="topic-metadata">

**Author:** [@knoblauch](https://internals.rust-lang.org/u/knoblauch)\
**Replies:** 2\
**Last updated:** [October 25, 2026, 5:02pm UTC](https://internals.rust-lang.org/t/read-le-and-read-be-exist-but-write-le-and-write-be-dont/24707 "2026-10-25T17:02:40Z")

</div>

Hey, i just found read\_le and its be counterpart but can't find write\_le and write\_be in the Write trait. I think that they should be added, because they would be very convenient.

---

## [Feature Request: Use Arc in constants](https://internals.rust-lang.org/t/feature-request-use-arc-in-constants/24682)

<div class="topic-metadata">

**Author:** [@burningtnt](https://internals.rust-lang.org/u/burningtnt)\
**Replies:** 17\
**Last updated:** [October 24, 2026, 3:45pm UTC](https://internals.rust-lang.org/t/feature-request-use-arc-in-constants/24682 "2026-10-24T15:45:18Z")

</div>

Consider the following situation: static GLOBAL: Mutex\<Arc\<Vec\>\> = Mutex::new( ... ) Programmers can't make this happen now, as there's no way to construct an Arc in constants with compile-time evaluation. We can make …

---

## [💡 Proposal: Add \`include\_c\_str!\` Macro to Rust](https://internals.rust-lang.org/t/proposal-add-include-c-str-macro-to-rust/23772)

<div class="topic-metadata">

**Author:** [@jmjoy](https://internals.rust-lang.org/u/jmjoy)\
**Replies:** 9\
**Last updated:** [October 21, 2026, 12:12am UTC](https://internals.rust-lang.org/t/proposal-add-include-c-str-macro-to-rust/23772 "2026-10-21T00:12:59Z")

</div>

The Rust language provides excellent build-time embedding tools with the existing include\_str! and include\_bytes! macros, allowing us to embed static file content directly into the final binary. These are incredibly usef…

---

## [Should std have an Arena type?](https://internals.rust-lang.org/t/should-std-have-an-arena-type/24653)

<div class="topic-metadata">

**Author:** [@cheese\_space](https://internals.rust-lang.org/u/cheese_space)\
**Replies:** 21\
**Last updated:** [October 15, 2026, 4:28am UTC](https://internals.rust-lang.org/t/should-std-have-an-arena-type/24653 "2026-10-15T04:28:52Z")

</div>

While I was making my own Arena as a little side project, I wondered why the stdlib doesn't have an Arena type. It has many other common data types like Vec, VecDeque, BinaryHeap etc. So my question is do you all think t…

---

## [Unsafe low-level mutex](https://internals.rust-lang.org/t/unsafe-low-level-mutex/24565)

<div class="topic-metadata">

**Author:** [@wyfo](https://internals.rust-lang.org/u/wyfo)\
**Replies:** 16\
**Last updated:** [October 8, 2026, 6:45pm UTC](https://internals.rust-lang.org/t/unsafe-low-level-mutex/24565 "2026-10-08T18:45:39Z")

</div>

When using a Mutex\<()\> in low-level unsafe code, keeping around the guard in order to unlock can be tedious/suboptimal (and poisoning can be useless and thus suboptimal in panic-free code). It's unfortunate because std …

---

## [\`std::slice::chunk\_by\_key\` missing - oversight?](https://internals.rust-lang.org/t/std-chunk-by-key-missing-oversight/24651)

<div class="topic-metadata">

**Author:** [@phimuemue](https://internals.rust-lang.org/u/phimuemue)\
**Replies:** 1\
**Last updated:** [October 2, 2026, 9:39pm UTC](https://internals.rust-lang.org/t/std-chunk-by-key-missing-oversight/24651 "2026-10-02T21:39:37Z")

</div>

There's slice::chunk\_by, but no slice::chunk\_by\_key, which might be helpful because it could: Evaluate the "key" once per element and re-use it for subsequent comparisons. Supply the "key" in addition to the chunk, avo…

---

## [Is there a reason there's no get\_disjoint\_mut for BTreeMap?](https://internals.rust-lang.org/t/is-there-a-reason-theres-no-get-disjoint-mut-for-btreemap/24626)

<div class="topic-metadata">

**Author:** [@Ryan1729](https://internals.rust-lang.org/u/Ryan1729)\
**Replies:** 3\
**Last updated:** [September 28, 2026, 3:36pm UTC](https://internals.rust-lang.org/t/is-there-a-reason-theres-no-get-disjoint-mut-for-btreemap/24626 "2026-09-28T15:36:16Z")

</div>

I ran into a case today where it would be nice to be able to get mutable references to multiple of the values stored in a BTreeMap. I notice that get\_disjoint\_mut exists on slice and also exists on HashMap. I don't kno…

---

## [Help needed: rust-analyzer error during libs development \[solved\]](https://internals.rust-lang.org/t/help-needed-rust-analyzer-error-during-libs-development-solved/24636)

<div class="topic-metadata">

**Author:** [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\
**Replies:** 0\
**Last updated:** [September 28, 2026, 9:40am UTC](https://internals.rust-lang.org/t/help-needed-rust-analyzer-error-during-libs-development-solved/24636 "2026-09-28T09:40:13Z")

</div>

EDIT: After a bit more debugging and then searching - I found r-a fails to parse \`core\` due to \`const\` closure · Issue #23006 · rust-lang/rust-analyzer

---

## [Trait for peekable iterators](https://internals.rust-lang.org/t/trait-for-peekable-iterators/24616)

<div class="topic-metadata">

**Author:** [@JarredAllen](https://internals.rust-lang.org/u/JarredAllen)\
**Replies:** 7\
**Last updated:** [September 27, 2026, 8:59am UTC](https://internals.rust-lang.org/t/trait-for-peekable-iterators/24616 "2026-09-27T08:59:17Z")

</div>

There's some useful methods on core::iter::Peekable, but those require making an adapter around your trait and then you can't ever get the original iterator back. Since many iterators could peek at their next element, it…

---

## [Make Vec and String be slices](https://internals.rust-lang.org/t/make-vec-and-string-be-slices/24540)

<div class="topic-metadata">

**Author:** [@Dwarsloeper](https://internals.rust-lang.org/u/Dwarsloeper)\
**Replies:** 15\
**Last updated:** [September 17, 2026, 11:00pm UTC](https://internals.rust-lang.org/t/make-vec-and-string-be-slices/24540 "2026-09-17T23:00:49Z")

</div>

IMHO Vecs and Strings are wasteful in storing the capacity along with the pointer and length. On 64bit systems this makes them to big to fit into u128 registers, where available. And on every move there is an extra usize…

---

## [Feature request: Stabilize \`NumBufferTrait\` to use as a bound](https://internals.rust-lang.org/t/feature-request-stabilize-numbuffertrait-to-use-as-a-bound/24581)

<div class="topic-metadata">

**Author:** [@tyilo](https://internals.rust-lang.org/u/tyilo)\
**Replies:** 6\
**Last updated:** [September 9, 2026, 1:26pm UTC](https://internals.rust-lang.org/t/feature-request-stabilize-numbuffertrait-to-use-as-a-bound/24581 "2026-09-09T13:26:34Z")

</div>

I would like to add the format\_into function to my Integer trait. This doesn't seem to be possible because of the T: NumBufferTrait bound in the definition of NumBuffer which requires me to add NumBufferTrait as a super…

---

## [Option\<NonNull\<T\>\>::as\_ptr](https://internals.rust-lang.org/t/option-nonnull-t-as-ptr/24563)

<div class="topic-metadata">

**Author:** [@wyfo](https://internals.rust-lang.org/u/wyfo)\
**Replies:** 2\
**Last updated:** [August 30, 2026, 9:01pm UTC](https://internals.rust-lang.org/t/option-nonnull-t-as-ptr/24563 "2026-08-30T21:01:26Z")

</div>

When working with raw pointers, using NonNull\<T\> and sometimes Option\<NonNull\<T\>\> can be more ergonomic. However, some APIs, e.g. AtomicPtr, requires raw pointers. NonNull has a as\_ptr method, but when it comes to Option\<…

---

## [Feature request: \`std::io::Sink\` should implement \`std::io::IsTerminal\` (returning \`false\`)](https://internals.rust-lang.org/t/feature-request-std-sink-should-implement-std-isterminal-returning-false/24561)

<div class="topic-metadata">

**Author:** [@gignico](https://internals.rust-lang.org/u/gignico)\
**Replies:** 2\
**Last updated:** [August 28, 2026, 4:02pm UTC](https://internals.rust-lang.org/t/feature-request-std-sink-should-implement-std-isterminal-returning-false/24561 "2026-08-28T16:02:35Z")

</div>

I have a tool which formats output and error messages on the terminal depending on the terminal size and therefore needs to query io::IsTerminal often. I have a trait RenderTarget: io::Write + io::IsTerminal which is use…

---

## [Pre-RFC: is\_x86\_feature\_detected! in core](https://internals.rust-lang.org/t/pre-rfc-is-x86-feature-detected-in-core/24538)

<div class="topic-metadata">

**Author:** [@hsivonen](https://internals.rust-lang.org/u/hsivonen)\
**Replies:** 0\
**Last updated:** [August 18, 2026, 7:58am UTC](https://internals.rust-lang.org/t/pre-rfc-is-x86-feature-detected-in-core/24538 "2026-08-18T07:58:08Z")

</div>

Summary Make the is\_x86\_feature\_detected! macro available in core on x86 and x86\_64 targets. Motivation It's common for crates that only perform computation to sooner or later to get a request to work as no\_std crates, …

---

## [\`alloc\`-only \`HashMap\`?](https://internals.rust-lang.org/t/alloc-only-hashmap/24071)

<div class="topic-metadata">

**Author:** [@JarredAllen](https://internals.rust-lang.org/u/JarredAllen)\
**Replies:** 20\
**Last updated:** [August 2, 2026, 8:09pm UTC](https://internals.rust-lang.org/t/alloc-only-hashmap/24071 "2026-08-02T20:09:33Z")

</div>

There have been times when I wanted HashMap/HashSet in some code which only has alloc to work with, but the default BuildHasher implementation being std-only prevents that from working. What stops us from just moving th…

---

## [Vibe check: \`rem\_euclid\_unsigned\`](https://internals.rust-lang.org/t/vibe-check-rem-euclid-unsigned/24484)

<div class="topic-metadata">

**Author:** [@jdahlstrom](https://internals.rust-lang.org/u/jdahlstrom)\
**Replies:** 5\
**Last updated:** [July 25, 2026, 2:49pm UTC](https://internals.rust-lang.org/t/vibe-check-rem-euclid-unsigned/24484 "2026-07-25T14:49:17Z")

</div>

Before firing off an ACP, just checking that I haven't missed anything. Not sure if this was discussed when the \_euclid() methods were first introduced. Motivation: I recently wrote some wrapper code that allows index…

---

## [Maybe a fix for error rounding behaviour of div\_euclid](https://internals.rust-lang.org/t/maybe-a-fix-for-error-rounding-behaviour-of-div-euclid/24403)

<div class="topic-metadata">

**Author:** [@Neutron3529](https://internals.rust-lang.org/u/Neutron3529)\
**Replies:** 13\
**Last updated:** [June 25, 2026, 10:35pm UTC](https://internals.rust-lang.org/t/maybe-a-fix-for-error-rounding-behaviour-of-div-euclid/24403 "2026-06-25T22:35:40Z")

</div>

TL;DR: 11f32.div\_euclid(2.2f32) yields 5 but should be 4. I'm trying fix it. I had asked deepseek about how to fix the rounding behaviour of div\_euclid function. Here shows what I got: #!\[feature(core\_float\_math)\] use…

---

## [Parser error recovery in \`syn\` for better IDE support with proc-macros](https://internals.rust-lang.org/t/parser-error-recovery-in-syn-for-better-ide-support-with-proc-macros/24362)

<div class="topic-metadata">

**Author:** [@programmerjake](https://internals.rust-lang.org/u/programmerjake)\
**Replies:** 22\
**Last updated:** [June 16, 2026, 10:30am UTC](https://internals.rust-lang.org/t/parser-error-recovery-in-syn-for-better-ide-support-with-proc-macros/24362 "2026-06-16T10:30:29Z")

</div>

@ekuber Creating a new thread here as you requested.

---

## [What is Allocator::by\_ref for?](https://internals.rust-lang.org/t/what-is-allocator-by-ref-for/24356)

<div class="topic-metadata">

**Author:** [@FeldrinH](https://internals.rust-lang.org/u/FeldrinH)\
**Replies:** 10\
**Last updated:** [May 26, 2026, 3:48pm UTC](https://internals.rust-lang.org/t/what-is-allocator-by-ref-for/24356 "2026-05-26T15:48:50Z")

</div>

I was looking at the Allocator API that is currently being stabilized and noticed that it has an Allocator::by\_ref method. I don't really understand what that method is for. It seems to simply return a shared reference …

---

## [Semantic of smart pointers](https://internals.rust-lang.org/t/semantic-of-smart-pointers/24345)

<div class="topic-metadata">

**Author:** [@Evian-Zhang](https://internals.rust-lang.org/u/Evian-Zhang)\
**Replies:** 2\
**Last updated:** [May 19, 2026, 3:15pm UTC](https://internals.rust-lang.org/t/semantic-of-smart-pointers/24345 "2026-05-19T15:15:10Z")

</div>

"Smart pointer" is an individual concept in The Rust Programming Language book. However, I didn't find a semantic-level definition of what "smart pointer" is. Should there be some traits in core/std to provide this seman…

---

## [\`Instant::PAST\_VALUE\` constant?](https://internals.rust-lang.org/t/instant-past-value-constant/24297)

<div class="topic-metadata">

**Author:** [@JarredAllen](https://internals.rust-lang.org/u/JarredAllen)\
**Replies:** 15\
**Last updated:** [May 16, 2026, 10:18pm UTC](https://internals.rust-lang.org/t/instant-past-value-constant/24297 "2026-05-16T22:18:34Z")

</div>

I often find that it would be useful to have a value for Instant which is some arbitrary point in time which is guaranteed to be in the past. On Linux (which I know most about), this should be doable by just creating Tim…

---

## [core::path::Path](https://internals.rust-lang.org/t/core-path/24233)

<div class="topic-metadata">

**Author:** [@t4ce](https://internals.rust-lang.org/u/t4ce)\
**Replies:** 7\
**Last updated:** [May 12, 2026, 1:21am UTC](https://internals.rust-lang.org/t/core-path/24233 "2026-05-12T01:21:07Z")

</div>

Hello Rustians! I’m not proposing an API yet; I’m trying to understand whether this direction has already been considered or is architectually blocked. The idea: Path feel like it could share a template/pattern-style a…

---

## [\[Pre-RFC\] Peeking from Peekable with less unwrapping](https://internals.rust-lang.org/t/pre-rfc-peeking-from-peekable-with-less-unwrapping/24169)

<div class="topic-metadata">

**Author:** [@NamorNiradnug](https://internals.rust-lang.org/u/NamorNiradnug)\
**Replies:** 4\
**Last updated:** [May 8, 2026, 7:24pm UTC](https://internals.rust-lang.org/t/pre-rfc-peeking-from-peekable-with-less-unwrapping/24169 "2026-05-08T19:24:10Z")

</div>

We have next\_if and some other methods for conditional iteration over Peekable. The problem is that these methods are not really composable. Usually it is easier to use peek, do something with the peeked value and then d…

---

## [\`std::marker::PhantomUnsized\` marker type](https://internals.rust-lang.org/t/std-phantomunsized-marker-type/24219)

<div class="topic-metadata">

**Author:** [@ds84182](https://internals.rust-lang.org/u/ds84182)\
**Replies:** 5\
**Last updated:** [May 6, 2026, 6:11pm UTC](https://internals.rust-lang.org/t/std-phantomunsized-marker-type/24219 "2026-05-06T18:11:25Z")

</div>

in library/core/src/marker.rs: /// A marker type without a compile-time or runtime defined size. /// /// This is distinct from other dynamically-sized types as it does not have /// pointer metadata. References/pointers …

---

## [Is interning as a general primitive something that should be in the standard library?](https://internals.rust-lang.org/t/is-interning-as-a-general-primitive-something-that-should-be-in-the-standard-library/24215)

<div class="topic-metadata">

**Author:** [@Andyou007](https://internals.rust-lang.org/u/Andyou007)\
**Replies:** 5\
**Last updated:** [May 2, 2026, 11:24pm UTC](https://internals.rust-lang.org/t/is-interning-as-a-general-primitive-something-that-should-be-in-the-standard-library/24215 "2026-05-02T23:24:20Z")

</div>

Title: Pre-RFC: List and VariableList: identity-based storage primitives with interning Every system that accepts input from humans operates on two concepts that are currently absent from core: A way to store and retr…

---

## [Could collections hypothetically store keys and values inline?](https://internals.rust-lang.org/t/could-collections-hypothetically-store-keys-and-values-inline/24195)

<div class="topic-metadata">

**Author:** [@robofinch](https://internals.rust-lang.org/u/robofinch)\
**Replies:** 19\
**Last updated:** [May 1, 2026, 3:15am UTC](https://internals.rust-lang.org/t/could-collections-hypothetically-store-keys-and-values-inline/24195 "2026-05-01T03:15:33Z")

</div>

Speaking only with respect to the default allocator: Vec\<T\> and String document that they never use any sort of "small optimization" where some \[T\] or str data is stored inline in the main Vec or String allocation. They…

---

## [\[Pre-RFC\] A tiny internal change to \`reverse\`, \`copy\_from\_slice\`, \`swap\_with\_slice\`](https://internals.rust-lang.org/t/pre-rfc-a-tiny-internal-change-to-reverse-copy-from-slice-swap-with-slice/24189)

<div class="topic-metadata">

**Author:** [@Lysxia](https://internals.rust-lang.org/u/Lysxia)\
**Replies:** 4\
**Last updated:** [April 27, 2026, 10:47pm UTC](https://internals.rust-lang.org/t/pre-rfc-a-tiny-internal-change-to-reverse-copy-from-slice-swap-with-slice/24189 "2026-04-27T22:47:27Z")

</div>

tl;dr: I propose to rewrite, for example, swap\_with\_slice from this current version (source) // Before (minimized) pub const fn swap\_with\_slice(&mut self, other: &mut \[T\]) { unsafe { ptr::swap\_nonoverlapping…

---

## [On usage of Custom Allocators](https://internals.rust-lang.org/t/on-usage-of-custom-allocators/24204)

<div class="topic-metadata">

**Author:** [@georgebarwood](https://internals.rust-lang.org/u/georgebarwood)\
**Replies:** 1\
**Last updated:** [April 26, 2026, 6:55am UTC](https://internals.rust-lang.org/t/on-usage-of-custom-allocators/24204 "2026-04-26T06:55:48Z")

</div>

Currently, on unstable, Vec (and other types such as Rc, Box etc) is being enhanced with a generic allocator parameter, wiht a default of Global. struct Vec\<T, A:Allocator=Global\>; I have been experimenting with cust…

---

## [Generic slice \`replace\`](https://internals.rust-lang.org/t/generic-slice-replace/24201)

<div class="topic-metadata">

**Author:** [@Rudxain](https://internals.rust-lang.org/u/Rudxain)\
**Replies:** 0\
**Last updated:** [April 25, 2026, 1:53am UTC](https://internals.rust-lang.org/t/generic-slice-replace/24201 "2026-04-25T01:53:03Z")

</div>

It'd be nice if this were generic: pub fn replace\<P\>(&self, from: P, to: &\[T\]) -\> Vec\<T\> where P: Pattern very related: Pre-RFC: New generic string pattern API for \`&str\`

[Next page](https://internals.rust-lang.org/c/libs/13.md?page=1)
