# Latest

**URL:** https://internals.rust-lang.org/latest.md?page=4

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

**Page:** 5

---

## [Typed keys as dyn-dispatchable method receivers](https://internals.rust-lang.org/t/typed-keys-as-dyn-dispatchable-method-receivers/24441)

<div class="topic-metadata">

**Author:** [@izagawd](https://internals.rust-lang.org/u/izagawd)\
**Replies:** 7\
**Last updated:** [July 7, 2026, 5:08pm UTC](https://internals.rust-lang.org/t/typed-keys-as-dyn-dispatchable-method-receivers/24441 "2026-07-07T17:08:54Z")

</div>

A lot of Rust game engines rely on deferring actions or on interior mutability, and one of the main reasons is: trait GameComponent { fn tick(&mut self, world: &mut World) {} } This can't compile in a useful way. t…

---

## [Language vision regarding safety guarantees](https://internals.rust-lang.org/t/language-vision-regarding-safety-guarantees/24418)

<div class="topic-metadata">

**Author:** [@ia0](https://internals.rust-lang.org/u/ia0)\
**Replies:** 78\
**Last updated:** [July 7, 2026, 12:24pm UTC](https://internals.rust-lang.org/t/language-vision-regarding-safety-guarantees/24418 "2026-07-07T12:24:51Z")

</div>

Summary There are regular statements that "safe code cannot cause UB", including from Rust team members. This statement is technically wrong because incomplete. A more complete statement would be "a unit of implementatio…

---

## [Rust 1.97.0 pre-release testing](https://internals.rust-lang.org/t/rust-1-97-0-pre-release-testing/24439)

<div class="topic-metadata">

**Author:** [@system](https://internals.rust-lang.org/u/system)\
**Replies:** 0\
**Last updated:** [July 7, 2026, 12:24pm UTC](https://internals.rust-lang.org/t/rust-1-97-0-pre-release-testing/24439 "2026-07-07T12:24:48Z")

</div>

The 1.97.0 pre-release is ready for testing. The release is scheduled for July 9. Release notes can be found here. You can try it out locally by running: RUSTUP\_DIST\_SERVER=https://dev-static.rust-lang.org rustup updat…

---

## [Insecure fn](https://internals.rust-lang.org/t/insecure-fn/24435)

<div class="topic-metadata">

**Author:** [@RelunSec](https://internals.rust-lang.org/u/RelunSec)\
**Replies:** 7\
**Last updated:** [July 7, 2026, 10:45am UTC](https://internals.rust-lang.org/t/insecure-fn/24435 "2026-07-07T10:45:23Z")

</div>

Hi, i request that feature because example let's have fn generate\_img\_src(url: String) -\> String { format!(r#"\<img src="{}" /\>"#, url) } that function is insecure because vulnerable to XSS, i propose something like …

---

## [Child Thread: Survey of registry namespace designs for Cargo and Crates.io](https://internals.rust-lang.org/t/child-thread-survey-of-registry-namespace-designs-for-cargo-and-crates-io/24030)

<div class="topic-metadata">

**Author:** [@epage](https://internals.rust-lang.org/u/epage)\
**Replies:** 9\
**Last updated:** [July 6, 2026, 1:55pm UTC](https://internals.rust-lang.org/t/child-thread-survey-of-registry-namespace-designs-for-cargo-and-crates-io/24030 "2026-07-06T13:55:29Z")

</div>

For background context and links to other threads, see Survey of organizational ownership and registry namespace designs for Cargo and Crates.io. This thread assumes that one has been read. This thread is for summarizi…

---

## [Child Thread: Survey of organizational ownership designs for Cargo and Crates.io](https://internals.rust-lang.org/t/child-thread-survey-of-organizational-ownership-designs-for-cargo-and-crates-io/24028)

<div class="topic-metadata">

**Author:** [@epage](https://internals.rust-lang.org/u/epage)\
**Replies:** 5\
**Last updated:** [July 6, 2026, 1:55pm UTC](https://internals.rust-lang.org/t/child-thread-survey-of-organizational-ownership-designs-for-cargo-and-crates-io/24028 "2026-07-06T13:55:07Z")

</div>

For background context and links to other threads, see Survey of organizational ownership and registry namespace designs for Cargo and Crates.io. This thread assumes that one has been read. This thread is for summarizi…

---

## [Yanking a crate better than deleting it](https://internals.rust-lang.org/t/yanking-a-crate-better-than-deleting-it/24175)

<div class="topic-metadata">

**Author:** [@RelunSec](https://internals.rust-lang.org/u/RelunSec)\
**Replies:** 5\
**Last updated:** [July 6, 2026, 11:08am UTC](https://internals.rust-lang.org/t/yanking-a-crate-better-than-deleting-it/24175 "2026-07-06T11:08:26Z")

</div>

Hello, Rust Team In security perspective, Yanking a crate on crates.io very better and block the name from attackers or threat actors, reregister deleted crates names and host malicious crates that harm users and users …

---

## [Support renames with \`link(name = "...", kind = "raw-dylib")\`](https://internals.rust-lang.org/t/support-renames-with-link-name-kind-raw-dylib/24415)

<div class="topic-metadata">

**Author:** [@davidhewitt](https://internals.rust-lang.org/u/davidhewitt)\
**Replies:** 10\
**Last updated:** [July 4, 2026, 6:56am UTC](https://internals.rust-lang.org/t/support-renames-with-link-name-kind-raw-dylib/24415 "2026-07-04T06:56:53Z")

</div>

The latest PyO3 version shipped changes to our windows builds to use the raw-dylib feature. I'm experiencing a fairly significant pain point with raw-dylib - it can't be "renamed" because raw-dylib isn't an accepted kin…

---

## [Code compiles on playground but fails when passed via stdin to rustc](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393)

<div class="topic-metadata">

**Author:** [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\
**Replies:** 41\
**Last updated:** [July 2, 2026, 5:21pm UTC](https://internals.rust-lang.org/t/code-compiles-on-playground-but-fails-when-passed-via-stdin-to-rustc/24393 "2026-07-02T17:21:33Z")

</div>

I've run into the following very strange behaviour and am unsure whether it's some kind of weird bug that I should report or a subtle mistake on my part. The following code compiles and runs fine on playground (as does …

---

## [Why is strict\_div implemented in terms of overflowing\_div for signed integers?](https://internals.rust-lang.org/t/why-is-strict-div-implemented-in-terms-of-overflowing-div-for-signed-integers/24387)

<div class="topic-metadata">

**Author:** [@QuaternionsRock](https://internals.rust-lang.org/u/QuaternionsRock)\
**Replies:** 3\
**Last updated:** [June 28, 2026, 2:39pm UTC](https://internals.rust-lang.org/t/why-is-strict-div-implemented-in-terms-of-overflowing-div-for-signed-integers/24387 "2026-06-28T14:39:58Z")

</div>

I was unable to find a satisfying answer to this question, so I thought I'd ask here. strict\_div is currently implemented as follows for signed integers: pub const fn strict\_div(self, rhs: Self) -\> Self { let (a, b)…

---

## [Negative trait bounds using feature(specialization)](https://internals.rust-lang.org/t/negative-trait-bounds-using-feature-specialization/24412)

<div class="topic-metadata">

**Author:** [@viruscamp](https://internals.rust-lang.org/u/viruscamp)\
**Replies:** 4\
**Last updated:** [June 27, 2026, 2:50pm UTC](https://internals.rust-lang.org/t/negative-trait-bounds-using-feature-specialization/24412 "2026-06-27T14:50:07Z")

</div>

Theoretically, this code should work. The library part compiles without any errors. The usage part can indeed reject the types that it is supposed to reject. However, the types that should be accepted are also being r…

---

## [Should \`.into()\` disrupt coercion?](https://internals.rust-lang.org/t/should-into-disrupt-coercion/24406)

<div class="topic-metadata">

**Author:** [@ItsNovaHere](https://internals.rust-lang.org/u/ItsNovaHere)\
**Replies:** 7\
**Last updated:** [June 27, 2026, 7:48am UTC](https://internals.rust-lang.org/t/should-into-disrupt-coercion/24406 "2026-06-27T07:48:43Z")

</div>

Currently, references are allowed to be coerced to pointers, and the docs for std::convert::Into says Into is reflexive, which means that Into\<T\> for T is implemented. I'm running into an issue where calling .into() whe…

---

## [Rust 1.96.1 pre-release testing](https://internals.rust-lang.org/t/rust-1-96-1-pre-release-testing/24417)

<div class="topic-metadata">

**Author:** [@system](https://internals.rust-lang.org/u/system)\
**Replies:** 0\
**Last updated:** [June 27, 2026, 3:25am UTC](https://internals.rust-lang.org/t/rust-1-96-1-pre-release-testing/24417 "2026-06-27T03:25:58Z")

</div>

The 1.96.1 pre-release is ready for testing. The release is scheduled for June 30. Release notes can be found here. You can try it out locally by running: RUSTUP\_DIST\_SERVER=https://dev-static.rust-lang.org rustup upda…

---

## [A read only no alias reference](https://internals.rust-lang.org/t/a-read-only-no-alias-reference/24410)

<div class="topic-metadata">

**Author:** [@NotPppp1116](https://internals.rust-lang.org/u/NotPppp1116)\
**Replies:** 15\
**Last updated:** [June 26, 2026, 5:46am UTC](https://internals.rust-lang.org/t/a-read-only-no-alias-reference/24410 "2026-06-26T05:46:36Z")

</div>

Pre-RFC: Exclusive shared references for read-only noalias borrows ## Summary Rust currently has two main reference modes: &T // shared, read-only-ish &mut T // exclusive, mutable This post proposes exploring a…

---

## [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…

---

## [\[Pre-RFC\] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets](https://internals.rust-lang.org/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225)

<div class="topic-metadata">

**Author:** [@nikkon-dev](https://internals.rust-lang.org/u/nikkon-dev)\
**Replies:** 17\
**Last updated:** [June 25, 2026, 8:05pm UTC](https://internals.rust-lang.org/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225 "2026-06-25T20:05:55Z")

</div>

Summary Add first-class support to rustc and cargo for declaring a binary's glibc deployment target — the oldest glibc release the binary is required to run on. Users opt in via either a target-tuple suffix (--target x86…

---

## [Should PGO automatically compile hot code O3 and cold code Oz?](https://internals.rust-lang.org/t/should-pgo-automatically-compile-hot-code-o3-and-cold-code-oz/24401)

<div class="topic-metadata">

**Author:** [@gmatht](https://internals.rust-lang.org/u/gmatht)\
**Replies:** 6\
**Last updated:** [June 24, 2026, 8:33am UTC](https://internals.rust-lang.org/t/should-pgo-automatically-compile-hot-code-o3-and-cold-code-oz/24401 "2026-06-24T08:33:06Z")

</div>

For example, by manually splitting the hot code of a simple benchmark into a library and compiling it at O3 while compiling the rest as Oz we end up with a binary that is strictly better than both Oz and O3... smaller th…

---

## [Err automatic hint::cold\_path?](https://internals.rust-lang.org/t/err-automatic-hint-cold-path/24404)

<div class="topic-metadata">

**Author:** [@Dwarsloeper](https://internals.rust-lang.org/u/Dwarsloeper)\
**Replies:** 3\
**Last updated:** [June 23, 2026, 8:47pm UTC](https://internals.rust-lang.org/t/err-automatic-hint-cold-path/24404 "2026-06-23T20:47:18Z")

</div>

Looking at this convert function, I was surprised that it doesn’t have a hint::cold\_path. IMHO both consuming and producing an error, doubly make the second branch a candidate. OTOH, if it didn’t have the const-hack, a ? …

---

## [".." in "use" statement](https://internals.rust-lang.org/t/in-use-statement/24405)

<div class="topic-metadata">

**Author:** [@syudoer](https://internals.rust-lang.org/u/syudoer)\
**Replies:** 9\
**Last updated:** [June 22, 2026, 10:47am UTC](https://internals.rust-lang.org/t/in-use-statement/24405 "2026-06-22T10:47:22Z")

</div>

Why is this not in the language yet? Why can't I just rename some items and then import the rest as-is, without importing the unrenamed versions too (unlike the \* operator)? I hope, if the demand is strong enough, it …

---

## [The Hashtable Problem: A Litmus Test for External Impl Proposals](https://internals.rust-lang.org/t/the-hashtable-problem-a-litmus-test-for-external-impl-proposals/24396)

<div class="topic-metadata">

**Author:** [@viruscamp](https://internals.rust-lang.org/u/viruscamp)\
**Replies:** 15\
**Last updated:** [June 18, 2026, 7:42am UTC](https://internals.rust-lang.org/t/the-hashtable-problem-a-litmus-test-for-external-impl-proposals/24396 "2026-06-18T07:42:41Z")

</div>

The Hashtable Problem: A Litmus Test for External Impl Proposals Any proposal aiming to relax the orphan rule or enable external trait implementations must address the hashtable problem. I met the problem when I wrote my…

---

## [Separating fetching from building for better security](https://internals.rust-lang.org/t/separating-fetching-from-building-for-better-security/24390)

<div class="topic-metadata">

**Author:** [@grothesque](https://internals.rust-lang.org/u/grothesque)\
**Replies:** 21\
**Last updated:** [June 17, 2026, 7:12pm UTC](https://internals.rust-lang.org/t/separating-fetching-from-building-for-better-security/24390 "2026-06-17T19:12:52Z")

</div>

Cargo and rust-analyzer are great, but their convenience comes with some security challenges: Like other language package managers, Cargo is subject to supply-chain attacks; Rust might be particularly exposed in that m…

---

## [\[Workable\] Selectable Named impl with Newtype Wrapper](https://internals.rust-lang.org/t/workable-selectable-named-impl-with-newtype-wrapper/24400)

<div class="topic-metadata">

**Author:** [@viruscamp](https://internals.rust-lang.org/u/viruscamp)\
**Replies:** 0\
**Last updated:** [June 16, 2026, 1:32pm UTC](https://internals.rust-lang.org/t/workable-selectable-named-impl-with-newtype-wrapper/24400 "2026-06-16T13:32:41Z")

</div>

I tried my best to simulate my Draft: Named impl with Implementation Selection Variant in current edition. The orginal idea is from wild hacked named impls by withoutboats use std::marker::PhantomData; pub trait Named…

---

## [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.

---

## [Infinite precision intermediate arithmetic: how much would break?](https://internals.rust-lang.org/t/infinite-precision-intermediate-arithmetic-how-much-would-break/24383)

<div class="topic-metadata">

**Author:** [@zackw](https://internals.rust-lang.org/u/zackw)\
**Replies:** 26\
**Last updated:** [June 14, 2026, 8:12pm UTC](https://internals.rust-lang.org/t/infinite-precision-intermediate-arithmetic-how-much-would-break/24383 "2026-06-14T20:12:08Z")

</div>

I wonder how much stuff would break if the rules for evaluating arithmetic expressions were changed like so: All arithmetic expressions are evaluated as-if in ℝ (or ℂ if necessary). In particular, all widening conversi…

---

## [Why can't pat\_param be followed by a colon in macro\_rules?](https://internals.rust-lang.org/t/why-cant-pat-param-be-followed-by-a-colon-in-macro-rules/24394)

<div class="topic-metadata">

**Author:** [@QuaternionsRock](https://internals.rust-lang.org/u/QuaternionsRock)\
**Replies:** 4\
**Last updated:** [June 13, 2026, 11:39pm UTC](https://internals.rust-lang.org/t/why-cant-pat-param-be-followed-by-a-colon-in-macro-rules/24394 "2026-06-13T23:39:44Z")

</div>

I wrote this macro only to discover that pat\_param fragments (otherwise known as PatternNoTopAlts cannot be followed by :s. As far as I can tell, PatternNoTopAlts cannot be terminated by a :. I get that there are potenti…

---

## [Add new reserved lifetime: 'owned](https://internals.rust-lang.org/t/add-new-reserved-lifetime-owned/24129)

<div class="topic-metadata">

**Author:** [@Voldemat](https://internals.rust-lang.org/u/Voldemat)\
**Replies:** 14\
**Last updated:** [June 13, 2026, 7:21pm UTC](https://internals.rust-lang.org/t/add-new-reserved-lifetime-owned/24129 "2026-06-13T19:21:11Z")

</div>

Problem statement: Right now rust treats all owned types like String as having 'static lifetime, meaning rust in terms of borrow checking sees &'static str and String as same. This creates issues when we try to make a st…

---

## [Named impl with Implementation Selection Variant](https://internals.rust-lang.org/t/named-impl-with-implementation-selection-variant/24374)

<div class="topic-metadata">

**Author:** [@viruscamp](https://internals.rust-lang.org/u/viruscamp)\
**Replies:** 10\
**Last updated:** [June 13, 2026, 9:52am UTC](https://internals.rust-lang.org/t/named-impl-with-implementation-selection-variant/24374 "2026-06-13T09:52:54Z")

</div>

Rust named impl Draft The purpose is clear: to bypass Rust's orphan rule. The proposed syntax should be more fluent to write, more natural to read, and more complete than the referenced proposals. Advantages Over Other…

---

## [Pre-RFC: Guarantee that pointers to \`OsStr\` has the same layout as pointers to \`str\`/\`\[u8\]\`](https://internals.rust-lang.org/t/pre-rfc-guarantee-that-pointers-to-osstr-has-the-same-layout-as-pointers-to-str-u8/24354)

<div class="topic-metadata">

**Author:** [@QuaternionsRock](https://internals.rust-lang.org/u/QuaternionsRock)\
**Replies:** 6\
**Last updated:** [June 12, 2026, 10:43pm UTC](https://internals.rust-lang.org/t/pre-rfc-guarantee-that-pointers-to-osstr-has-the-same-layout-as-pointers-to-str-u8/24354 "2026-06-12T22:43:29Z")

</div>

Rust makes vanishingly few guarantees about the layout of pointers to unsized types. To my knowledge, the only exception is that pointers to str have the same layout as pointers to \[u8\]. I propose extending this guarante…

---

## [Pre-RFC: Explicit overload sets for mixed-arity function calls](https://internals.rust-lang.org/t/pre-rfc-explicit-overload-sets-for-mixed-arity-function-calls/24372)

<div class="topic-metadata">

**Author:** [@ovior](https://internals.rust-lang.org/u/ovior)\
**Replies:** 17\
**Last updated:** [June 11, 2026, 9:34pm UTC](https://internals.rust-lang.org/t/pre-rfc-explicit-overload-sets-for-mixed-arity-function-calls/24372 "2026-06-11T21:34:58Z")

</div>

Pre-RFC: Explicit overload sets for mixed-arity function calls Problem Rust can express: draw(point); draw((x, y)); with traits, or: draw!(point); draw!(x, y); with macros, but it cannot express: draw(point); draw(x…

---

## [RACE: Semantic-linker approach to stable cross-crate ABI without runtime overhead](https://internals.rust-lang.org/t/race-semantic-linker-approach-to-stable-cross-crate-abi-without-runtime-overhead/24369)

<div class="topic-metadata">

**Author:** [@dvrkxed](https://internals.rust-lang.org/u/dvrkxed)\
**Replies:** 6\
**Last updated:** [June 9, 2026, 3:35pm UTC](https://internals.rust-lang.org/t/race-semantic-linker-approach-to-stable-cross-crate-abi-without-runtime-overhead/24369 "2026-06-09T15:35:13Z")

</div>

This is a pre-RFC exploration. Presenting it to gather feedback before considering a formal RFC. Problem Rust currently has no stable ABI. This is a deliberate and reasonable decision — it allows the compiler to optim…

[Previous page](https://internals.rust-lang.org/latest.md?page=3)

[Next page](https://internals.rust-lang.org/latest.md?page=5)
