# libs

**URL:** https://internals.rust-lang.org/c/libs/13.md?page=2

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

**Page:** 3

---

## [Immutable equivalent of IntoIterator](https://internals.rust-lang.org/t/immutable-equivalent-of-intoiterator/23625)

<div class="topic-metadata">

**Author:** [@JonathanWilbur](https://internals.rust-lang.org/u/JonathanWilbur)\
**Replies:** 5\
**Last updated:** [October 17, 2025, 12:08am UTC](https://internals.rust-lang.org/t/immutable-equivalent-of-intoiterator/23625 "2025-10-17T00:08:08Z")

</div>

Hello, Recently, I was trying to implement a generic function that takes any type that can return an iterator without consuming the type. IntoIterator was insufficient for my use case, because I need to be able to re-us…

---

## [Pre-ACP: floor halve with remainder](https://internals.rust-lang.org/t/pre-acp-floor-halve-with-remainder/23617)

<div class="topic-metadata">

**Author:** [@ais523](https://internals.rust-lang.org/u/ais523)\
**Replies:** 10\
**Last updated:** [October 14, 2025, 2:06pm UTC](https://internals.rust-lang.org/t/pre-acp-floor-halve-with-remainder/23617 "2025-10-14T14:06:37Z")

</div>

Many processors (including many widely used ones) support an operation that divides a number by 2, rounding towards negative infinity, and also returning whether it was odd or even. In Rust, this would look something lik…

---

## [\`is\_...\` functions on char should have a unifed API](https://internals.rust-lang.org/t/is-functions-on-char-should-have-a-unifed-api/23584)

<div class="topic-metadata">

**Author:** [@ljtpetersen](https://internals.rust-lang.org/u/ljtpetersen)\
**Replies:** 4\
**Last updated:** [October 2, 2025, 3:45am UTC](https://internals.rust-lang.org/t/is-functions-on-char-should-have-a-unifed-api/23584 "2025-10-02T03:45:50Z")

</div>

Here are two functions on char: pub const fn is\_whitespace(self) -\> bool { /\* ... \*/ } pub const fn is\_ascii(&self) -\> bool { /\* ... \*/ } These have essentially the same signature. However, "abc".find(char::is\_whitespa…

---

## [Constant-time selection intrinsics](https://internals.rust-lang.org/t/constant-time-selection-intrinsics/23565)

<div class="topic-metadata">

**Author:** [@frabert](https://internals.rust-lang.org/u/frabert)\
**Replies:** 6\
**Last updated:** [October 1, 2025, 4:58pm UTC](https://internals.rust-lang.org/t/constant-time-selection-intrinsics/23565 "2025-10-01T16:58:12Z")

</div>

Hi everyone! We at Trail of Bits are currently working on adding support for constant-time guaranteed selection intrinsics to LLVM (see our RFC on the LLVM forum). We are considering proposing a mechanism to make this fe…

---

## [Implement ExactSizeIterator for \`Zip\<A, Repeat\<B\>\> where A: ExactSizeIterator, B: Clone\`](https://internals.rust-lang.org/t/implement-exactsizeiterator-for-zip-a-repeat-b-where-a-exactsizeiterator-b-clone/23537)

<div class="topic-metadata">

**Author:** [@414owen](https://internals.rust-lang.org/u/414owen)\
**Replies:** 10\
**Last updated:** [September 23, 2025, 10:06am UTC](https://internals.rust-lang.org/t/implement-exactsizeiterator-for-zip-a-repeat-b-where-a-exactsizeiterator-b-clone/23537 "2025-09-23T10:06:15Z")

</div>

This is a proposal to add two instances: impl\<A, B\> ExactSizeIterator for Zip\<A, Repeat\<B\>\> where A: ExactSizeIterator, B: Clone, { } impl\<A, B\> ExactSizeIterator for Zip\<Repeat\<A\>, B\> where A: Clone, B…

---

## [Add float types with niche](https://internals.rust-lang.org/t/add-float-types-with-niche/23429)

<div class="topic-metadata">

**Author:** [@creight](https://internals.rust-lang.org/u/creight)\
**Replies:** 16\
**Last updated:** [September 13, 2025, 1:33pm UTC](https://internals.rust-lang.org/t/add-float-types-with-niche/23429 "2025-09-13T13:33:24Z")

</div>

Considering that stable and flexible custom niche optimizations are still a long way off, should Rust's standard library add floating-point types with niches, such as FiniteF\* or NonNaNF\* ? This would allow direct and co…

---

## [Why are Drain types not #\[must\_use\]?](https://internals.rust-lang.org/t/why-are-drain-types-not-must-use/23513)

<div class="topic-metadata">

**Author:** [@akrauze](https://internals.rust-lang.org/u/akrauze)\
**Replies:** 11\
**Last updated:** [September 11, 2025, 7:40pm UTC](https://internals.rust-lang.org/t/why-are-drain-types-not-must-use/23513 "2025-09-11T19:40:19Z")

</div>

I was reading a topic on main forum, when I realised that neither Drain types in std nor drain functions that return them are marked as #\[must\_use\]. This makes following code compile without warnings: fn main() { le…

---

## [F64::midpoint](https://internals.rust-lang.org/t/f64-midpoint/23491)

<div class="topic-metadata">

**Author:** [@Chris00](https://internals.rust-lang.org/u/Chris00)\
**Replies:** 3\
**Last updated:** [September 5, 2025, 5:42am UTC](https://internals.rust-lang.org/t/f64-midpoint/23491 "2025-09-05T05:42:04Z")

</div>

Hi, I was looking at the f64::midpoint implementation and was wondering why it does not use the paper “How do you compute the midpoint of an interval?“ (HAL) which, IMHO, behaves better. Best, Christophe

---

## [\`fmt::Arguments\` expose \`pieces\`. Maybe add \`write\_static\_str\` to \`Write\`?](https://internals.rust-lang.org/t/fmt-arguments-expose-pieces-maybe-add-write-static-str-to-write/23479)

<div class="topic-metadata">

**Author:** [@Ddystopia](https://internals.rust-lang.org/u/Ddystopia)\
**Replies:** 2\
**Last updated:** [September 4, 2025, 7:29am UTC](https://internals.rust-lang.org/t/fmt-arguments-expose-pieces-maybe-add-write-static-str-to-write/23479 "2025-09-04T07:29:21Z")

</div>

Today, fmt::Argments has as\_str method which returns &'static str for formats like format\_args!("foo"). Internally it has pieces: &'a \[&'static str\], and for what I work on it would really save me a lot of memory and res…

---

## [\[Pre-RFC\] Add implementation impl\<T, U\> Borrow\<T\> for Arc\<U: Deref\<Target=T\>\> and similar for Rc](https://internals.rust-lang.org/t/pre-rfc-add-implementation-impl-t-u-borrow-t-for-arc-u-deref-target-t-and-similar-for-rc/23467)

<div class="topic-metadata">

**Author:** [@mgalczynski](https://internals.rust-lang.org/u/mgalczynski)\
**Replies:** 2\
**Last updated:** [August 28, 2025, 6:42pm UTC](https://internals.rust-lang.org/t/pre-rfc-add-implementation-impl-t-u-borrow-t-for-arc-u-deref-target-t-and-similar-for-rc/23467 "2025-08-28T18:42:31Z")

</div>

Summary Add new implementation impl\<T, U\> Borrow\<T\> for Arc\<U: Deref\<Target=T\>\> and similar for Rc Motivation Currently collections: BTreeSet and HashMap, when using Arc or Rc as key, need same type as in Arc or Rc to b…

---

## [Generic impl Write for Arc\<T\> where &T: Write](https://internals.rust-lang.org/t/generic-impl-write-for-arc-t-where-t-write/23452)

<div class="topic-metadata">

**Author:** [@IoaNNUwU](https://internals.rust-lang.org/u/IoaNNUwU)\
**Replies:** 1\
**Last updated:** [August 25, 2025, 10:30pm UTC](https://internals.rust-lang.org/t/generic-impl-write-for-arc-t-where-t-write/23452 "2025-08-25T22:30:38Z")

</div>

std::fs::File has this impl that allows to use it inside Arc: impl Write for Arc\<File\> { } This impl is possible because &File also implements Write: impl Write for &File { } If I have my own Write implementation for…

---

## [IDEA: unify lifetime in function signature](https://internals.rust-lang.org/t/idea-unify-lifetime-in-function-signature/23448)

<div class="topic-metadata">

**Author:** [@earthengine](https://internals.rust-lang.org/u/earthengine)\
**Replies:** 1\
**Last updated:** [August 24, 2025, 4:30pm UTC](https://internals.rust-lang.org/t/idea-unify-lifetime-in-function-signature/23448 "2025-08-24T16:30:45Z")

</div>

Many times, I found the need to ask the compiler to unify the lifetime in function signatures. For example, the signature below trait User { fn update\_user\_name(&self, name: &str) -\> Pin\<Box\<dyn Future\<Output=()\> +…

---

## [\[Pre-RFC\] Hash for ZST slices Hash not to iterate](https://internals.rust-lang.org/t/pre-rfc-hash-for-zst-slices-hash-not-to-iterate/23447)

<div class="topic-metadata">

**Author:** [@peter-lyons-kehl](https://internals.rust-lang.org/u/peter-lyons-kehl)\
**Replies:** 2\
**Last updated:** [August 24, 2025, 8:15am UTC](https://internals.rust-lang.org/t/pre-rfc-hash-for-zst-slices-hash-not-to-iterate/23447 "2025-08-24T08:15:00Z")

</div>

Summary Problem: Current implementation of Hash for ZST slices iterates over items. That times out for very large ones (usize::MAX). Suggested change: Hash::hash\_slice(...) not to iterate (and not to call hash on its it…

---

## [\[Pre-ACP\] Add methods to \`VecDeque\` to get spare capacity](https://internals.rust-lang.org/t/pre-acp-add-methods-to-vecdeque-to-get-spare-capacity/23413)

<div class="topic-metadata">

**Author:** [@JarredAllen](https://internals.rust-lang.org/u/JarredAllen)\
**Replies:** 5\
**Last updated:** [August 19, 2025, 7:50pm UTC](https://internals.rust-lang.org/t/pre-acp-add-methods-to-vecdeque-to-get-spare-capacity/23413 "2025-08-19T19:50:40Z")

</div>

The Vec type has methods for accessing spare capacity, so you can directly write to the uninitialized memory and then update the length. But VecDeque has no such access, and I recently came across some code where it woul…

---

## [Async-std deprecation](https://internals.rust-lang.org/t/async-std-deprecation/23395)

<div class="topic-metadata">

**Author:** [@harmic](https://internals.rust-lang.org/u/harmic)\
**Replies:** 5\
**Last updated:** [August 16, 2025, 10:39pm UTC](https://internals.rust-lang.org/t/async-std-deprecation/23395 "2025-08-16T22:39:55Z")

</div>

First - apologies if this is not the right forum to raise this. I raised a bug report on the async-std github repo back in May but got no response. According to the README in the async-std repo, async-std has been disco…

---

## [Add some methods for std::borrow::Cow](https://internals.rust-lang.org/t/add-some-methods-for-std-cow/23375)

<div class="topic-metadata">

**Author:** [@algosul](https://internals.rust-lang.org/u/algosul)\
**Replies:** 3\
**Last updated:** [August 12, 2025, 6:28pm UTC](https://internals.rust-lang.org/t/add-some-methods-for-std-cow/23375 "2025-08-12T18:28:52Z")

</div>

Add some methods for std::borrow::Cow The cause of the problem: I was writing a program to launch an external program. When adding a large number of parameters, I wanted to convert Iterator\<Item=Cow\<'\_, ...\>\> to Iterato…

---

## [\[Idea\] Faster derive(Hash) for types without padding](https://internals.rust-lang.org/t/idea-faster-derive-hash-for-types-without-padding/23305)

<div class="topic-metadata">

**Author:** [@Sawyer47](https://internals.rust-lang.org/u/Sawyer47)\
**Replies:** 26\
**Last updated:** [August 12, 2025, 9:50pm UTC](https://internals.rust-lang.org/t/idea-faster-derive-hash-for-types-without-padding/23305 "2025-08-12T21:50:33Z")

</div>

Hi everyone, I am new here. After reading a blog post about hashing in Rust I was thinking how the situation could be improved. My first thought was that if Rust had an equivalent of C++’s has\_unique\_object\_representati…

---

## [&mut \[u8\] and core::fmt::Write](https://internals.rust-lang.org/t/mut-u8-and-core-write/23369)

<div class="topic-metadata">

**Author:** [@Strackeror](https://internals.rust-lang.org/u/Strackeror)\
**Replies:** 2\
**Last updated:** [August 12, 2025, 11:44am UTC](https://internals.rust-lang.org/t/mut-u8-and-core-write/23369 "2025-08-12T11:44:00Z")

</div>

So, in std, there's this quite elegant pattern that's available to format into a byte buffer: use std::io::Write; fn toast() { let mut buf = \[0u8, 10\]; let mut slice = &mut buf\[..\]; let integer = 0; wri…

---

## [Support comparison policies in HashMap](https://internals.rust-lang.org/t/support-comparison-policies-in-hashmap/23266)

<div class="topic-metadata">

**Author:** [@CodesInChaos](https://internals.rust-lang.org/u/CodesInChaos)\
**Replies:** 7\
**Last updated:** [August 9, 2025, 8:32pm UTC](https://internals.rust-lang.org/t/support-comparison-policies-in-hashmap/23266 "2025-08-09T20:32:56Z")

</div>

Currently HashMap and HashSet rely on the inherent implementations of the Eq and Hash traits. I propose moving this behaviour to the S (RandomState) parameter. This change is backwards compatible, but improves flexibilit…

---

## [Proposal to add 'sandboxed' compile-time enforcement for element access](https://internals.rust-lang.org/t/proposal-to-add-sandboxed-compile-time-enforcement-for-element-access/23317)

<div class="topic-metadata">

**Author:** [@JamFactory](https://internals.rust-lang.org/u/JamFactory)\
**Replies:** 7\
**Last updated:** [August 4, 2025, 11:09pm UTC](https://internals.rust-lang.org/t/proposal-to-add-sandboxed-compile-time-enforcement-for-element-access/23317 "2025-08-04T23:09:17Z")

</div>

Preface While this applies to more than just vectors, I will be focusing on them in my examples and proof of concept, as their API is relatively simple and they are the most ubiquitous and error-prone collection in my ex…

---

## [Safe narrowing casts in some cases](https://internals.rust-lang.org/t/safe-narrowing-casts-in-some-cases/23312)

<div class="topic-metadata">

**Author:** [@leonardo](https://internals.rust-lang.org/u/leonardo)\
**Replies:** 0\
**Last updated:** [August 2, 2025, 4:25pm UTC](https://internals.rust-lang.org/t/safe-narrowing-casts-in-some-cases/23312 "2025-08-02T16:25:33Z")

</div>

Probably I discussed part of this in past, but there's more material here, and it's sometimes good to repeat a bit, to be heard. In my code I try to avoid "as" casts where possible (and Clippy agrees), but also filling …

---

## [Pre-RFC: Safety Property System](https://internals.rust-lang.org/t/pre-rfc-safety-property-system/23252)

<div class="topic-metadata">

**Author:** [@vague](https://internals.rust-lang.org/u/vague)\
**Replies:** 36\
**Last updated:** [July 31, 2025, 2:51pm UTC](https://internals.rust-lang.org/t/pre-rfc-safety-property-system/23252 "2025-07-31T14:51:36Z")

</div>

The full proposal document is in our tag-std repository. It's too long to read in this post, considering there are more conversations going on. We are experimenting this feature on verify-rust-std, Rust for Linux, an…

---

## [Should there be Arc::ptr\_hash to compliment Arc::ptr\_eq?](https://internals.rust-lang.org/t/should-there-be-arc-ptr-hash-to-compliment-arc-ptr-eq/23262)

<div class="topic-metadata">

**Author:** [@findepi](https://internals.rust-lang.org/u/findepi)\
**Replies:** 6\
**Last updated:** [July 23, 2025, 1:59pm UTC](https://internals.rust-lang.org/t/should-there-be-arc-ptr-hash-to-compliment-arc-ptr-eq/23262 "2025-07-23T13:59:10Z")

</div>

When implementing PartialEq and Hash for a struct containing a raw pointer, assuming I want pointer equality semantics, I can use std::ptr::eq and std::ptr::hash functions. When the struct holds an Arc I can use Arc::p…

---

## [Should stdlib error type use Box\<str|\[u8\]\> instead of String|Vec\<u8\>?](https://internals.rust-lang.org/t/should-stdlib-error-type-use-box-str-u8-instead-of-string-vec-u8/23259)

<div class="topic-metadata">

**Author:** [@Dushistov](https://internals.rust-lang.org/u/Dushistov)\
**Replies:** 2\
**Last updated:** [July 23, 2025, 11:14am UTC](https://internals.rust-lang.org/t/should-stdlib-error-type-use-box-str-u8-instead-of-string-vec-u8/23259 "2025-07-23T11:14:40Z")

</div>

In all the Rust code I've read error types are used as read only types. So why not optimize code this case, in other words do not return capacity field as part of error type? For example NulError, it is struct NulError(…

---

## [Request to make \`rustc\_interface::passes::configure\_and\_expand\` public](https://internals.rust-lang.org/t/request-to-make-rustc-interface-configure-and-expand-public/23237)

<div class="topic-metadata">

**Author:** [@bwu25](https://internals.rust-lang.org/u/bwu25)\
**Replies:** 4\
**Last updated:** [July 16, 2025, 11:38pm UTC](https://internals.rust-lang.org/t/request-to-make-rustc-interface-configure-and-expand-public/23237 "2025-07-16T23:38:31Z")

</div>

Hello, I am wondering if it is possible to make rustc\_interface::passes::configure\_and\_expand public to call from a custom compiler driver written using the rustc\_interface crate. The first two callbacks rustc\_driver o…

---

## [Dynamically-linked stable shared subset of the Rust standard library — using the C ABI?](https://internals.rust-lang.org/t/dynamically-linked-stable-shared-subset-of-the-rust-standard-library-using-the-c-abi/23203)

<div class="topic-metadata">

**Author:** [@kornel](https://internals.rust-lang.org/u/kornel)\
**Replies:** 18\
**Last updated:** [July 14, 2025, 9:10pm UTC](https://internals.rust-lang.org/t/dynamically-linked-stable-shared-subset-of-the-rust-standard-library-using-the-c-abi/23203 "2025-07-14T21:10:14Z")

</div>

Recently, I've noticed that the overhead added by Rust's standard library to every Rust binary is too small! Every Rust executable already contains a symbolicator and a parser for external debug symbol archives. The arch…

---

## [Performance of isqrt](https://internals.rust-lang.org/t/performance-of-isqrt/23228)

<div class="topic-metadata">

**Author:** [@Neutron3529](https://internals.rust-lang.org/u/Neutron3529)\
**Replies:** 7\
**Last updated:** [July 14, 2025, 8:56pm UTC](https://internals.rust-lang.org/t/performance-of-isqrt/23228 "2025-07-14T20:56:54Z")

</div>

I'm really curious about the performance issues about isqrt, since they are quite long. There is a very simple idea come into my mind: Will it faster to convert u32 into f64, calculating its square root directly, and co…

---

## [CStr API extensions](https://internals.rust-lang.org/t/cstr-api-extensions/21832)

<div class="topic-metadata">

**Author:** [@CodesInChaos](https://internals.rust-lang.org/u/CodesInChaos)\
**Replies:** 1\
**Last updated:** [July 11, 2025, 1:42pm UTC](https://internals.rust-lang.org/t/cstr-api-extensions/21832 "2025-07-11T13:42:19Z")

</div>

I'm proposing two groups of enhancements to CStr: Ability to convert a c\_char pointer to a CStr pointer. This is useful to create an owning wrapper type around a CStr allocated by a C library. This could even be a gen…

---

## [Hooks for obtaining debug symbols for backtraces](https://internals.rust-lang.org/t/hooks-for-obtaining-debug-symbols-for-backtraces/23160)

<div class="topic-metadata">

**Author:** [@kornel](https://internals.rust-lang.org/u/kornel)\
**Replies:** 12\
**Last updated:** [July 8, 2025, 8:42pm UTC](https://internals.rust-lang.org/t/hooks-for-obtaining-debug-symbols-for-backtraces/23160 "2025-07-08T20:42:36Z")

</div>

When a Rust program panics, it tries to get symbols for the backtrace. In case of ELF executables, the symbols don't have to be in the same executable, and can be loaded from external locations via debug-id or GNU debugl…

---

## [Could \`Mutex\<T\>\` have been \`Mutex\<Poison\<T\>\>\`?](https://internals.rust-lang.org/t/could-mutex-t-have-been-mutex-poison-t/23180)

<div class="topic-metadata">

**Author:** [@kornel](https://internals.rust-lang.org/u/kornel)\
**Replies:** 6\
**Last updated:** [July 7, 2025, 2:17pm UTC](https://internals.rust-lang.org/t/could-mutex-t-have-been-mutex-poison-t/23180 "2025-07-07T14:17:09Z")

</div>

It's too late for libstd to change it, but I wonder if poisoning could have been made optional by separating it into another type. Currently, Mutex is a bundle of two features in one, which forces users to use poisoning…

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

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