# language design **URL:** https://internals.rust-lang.org/c/language-design/21.md?page=1 [Latest](https://internals.rust-lang.org/latest.md) · [Categories](https://internals.rust-lang.org/categories.md) **Page:** 2 --- ## [Idea: Alias as a common abstraction over Share and Reborrow](https://internals.rust-lang.org/t/idea-alias-as-a-common-abstraction-over-share-and-reborrow/24528)
**Author:** [@viktorlott](https://internals.rust-lang.org/u/viktorlott)\ **Replies:** 9\ **Last updated:** [August 17, 2026, 10:25am UTC](https://internals.rust-lang.org/t/idea-alias-as-a-common-abstraction-over-share-and-reborrow/24528 "2026-08-17T10:25:05Z")
I have been thinking about the relationship between the proposed Reborrow work and the recent Share/cheap-clone ideas. I think there may be a useful common abstraction above them: (Updated full design here) unsafe auto… --- ## [Idea: Optics types, combining pattern types and view types](https://internals.rust-lang.org/t/idea-optics-types-combining-pattern-types-and-view-types/24526)
**Author:** [@frank-king](https://internals.rust-lang.org/u/frank-king)\ **Replies:** 13\ **Last updated:** [August 17, 2026, 9:49am UTC](https://internals.rust-lang.org/t/idea-optics-types-combining-pattern-types-and-view-types/24526 "2026-08-17T09:49:31Z")
Here is a naive idea inspired by the optics (lens and prisms) in bidirectional transformation. Given the view types like lens that provides partial view and update for product types, and pattern types like prisms that pr… --- ## [Generic Variables: simple implicity context passing](https://internals.rust-lang.org/t/generic-variables-simple-implicity-context-passing/24509)
**Author:** [@Jed](https://internals.rust-lang.org/u/Jed)\ **Replies:** 36\ **Last updated:** [August 12, 2026, 11:11am UTC](https://internals.rust-lang.org/t/generic-variables-simple-implicity-context-passing/24509 "2026-08-12T11:11:25Z")
Hello everyone I have an idea for a new language feature to solve the problem of types that depend on runtime context to be meaningful. I also made a post about this on Zulip \[1\], but it isn't getting much traction so I… --- ## [Declarative macro re-invocation using \`self!\`, and macro arm privacy](https://internals.rust-lang.org/t/declarative-macro-re-invocation-using-self-and-macro-arm-privacy/24517)
**Author:** [@ds84182](https://internals.rust-lang.org/u/ds84182)\ **Replies:** 4\ **Last updated:** [August 12, 2026, 1:38am UTC](https://internals.rust-lang.org/t/declarative-macro-re-invocation-using-self-and-macro-arm-privacy/24517 "2026-08-12T01:38:53Z")
Sometimes a macro needs to use a helper macro to perform some operation (e.g. summing the number of items passed in). Declaring and exporting a secondary helper macro unfortunately allows a downstream crate to depend upo… --- ## [Named tuple fields (no type system changes)](https://internals.rust-lang.org/t/named-tuple-fields-no-type-system-changes/24413)
**Author:** [@ds84182](https://internals.rust-lang.org/u/ds84182)\ **Replies:** 7\ **Last updated:** [August 8, 2026, 11:45pm UTC](https://internals.rust-lang.org/t/named-tuple-fields-no-type-system-changes/24413 "2026-08-08T23:45:27Z")
Just allow adding names to tuple fields for documentation purposes. e.g. fn into\_raw\_parts(self) -\> (ptr: NonNull\, len: usize, cap: usize). Like function pointers, these do not change the type of the tuple. (a: u32, … --- ## [Discussions about the future of atomic primitives in rust](https://internals.rust-lang.org/t/discussions-about-the-future-of-atomic-primitives-in-rust/24475)
**Author:** [@panayang](https://internals.rust-lang.org/u/panayang)\ **Replies:** 20\ **Last updated:** [August 6, 2026, 7:37pm UTC](https://internals.rust-lang.org/t/discussions-about-the-future-of-atomic-primitives-in-rust/24475 "2026-08-06T19:37:09Z")
Hello, Rustaceans! As we all know, the atomic primitives and standards mostly comes from the C++ 11 atomic primitives standards and definitions. But in C++ 26, even C++ deprecated APIs like atomic\_load/store and moves t… --- ## [Const-first functions](https://internals.rust-lang.org/t/const-first-functions/24466)
**Author:** [@nazar-pc](https://internals.rust-lang.org/u/nazar-pc)\ **Replies:** 36\ **Last updated:** [August 6, 2026, 1:57pm UTC](https://internals.rust-lang.org/t/const-first-functions/24466 "2026-08-06T13:57:50Z")
Today, as far as I'm aware, Rust has two variants of const functions: const-capable functions that are only used as const when called from const context (regular const fn) "comptime" const functions that can only be ca… --- ## [\[feat\] \`#\[doctest(off)\]\` for forward comment scenario](https://internals.rust-lang.org/t/feat-doctest-off-for-forward-comment-scenario/24503)
**Author:** [@loynoir](https://internals.rust-lang.org/u/loynoir)\ **Replies:** 5\ **Last updated:** [August 5, 2026, 12:21pm UTC](https://internals.rust-lang.org/t/feat-doctest-off-for-forward-comment-scenario/24503 "2026-08-05T12:21:13Z")
feat #\[doctest(off)\] for forward comment scenario problem https://crates.io/crates/typify Crate typify have 26,523,578 total downloads. Test failures occur because comments are forwarded without being sanitized, due … --- ## [Strong updates status](https://internals.rust-lang.org/t/strong-updates-status/21074)
**Author:** [@ia0](https://internals.rust-lang.org/u/ia0)\ **Replies:** 47\ **Last updated:** [August 3, 2026, 7:28pm UTC](https://internals.rust-lang.org/t/strong-updates-status/21074 "2026-08-03T19:28:35Z")
TLDR: It seems to me strong updates would be quite beneficial and might not be "too hard" to provide given what Rust already provides. This thread aims at gauging where the community stands in that regard. (Is it somethi… --- ## [There should be a primitive int / float trait in core / stdlib](https://internals.rust-lang.org/t/there-should-be-a-primitive-int-float-trait-in-core-stdlib/24464)
**Author:** [@cheese\_space](https://internals.rust-lang.org/u/cheese_space)\ **Replies:** 19\ **Last updated:** [August 2, 2026, 8:10pm UTC](https://internals.rust-lang.org/t/there-should-be-a-primitive-int-float-trait-in-core-stdlib/24464 "2026-08-02T20:10:24Z")
This would be useful in cases were you want to use / store a number but don't care about a specific type of number for example: /// add two integers together pub fn add\(x: T, y: T) -\> T { x + y } T… --- ## [Why does the Drop trait take a mutable reference?](https://internals.rust-lang.org/t/why-does-the-drop-trait-take-a-mutable-reference/24468)
**Author:** [@cheese\_space](https://internals.rust-lang.org/u/cheese_space)\ **Replies:** 24\ **Last updated:** [July 25, 2026, 11:40am UTC](https://internals.rust-lang.org/t/why-does-the-drop-trait-take-a-mutable-reference/24468 "2026-07-25T11:40:59Z")
The drop trait is currently defined as: fn drop(&mut self) { // ... } But the thing is, after dropping the value, the value is no longer accessible. This is also the reason why you can't call the Drop trait expli… --- ## [Two-way vs. one-way unification when resolving traits](https://internals.rust-lang.org/t/two-way-vs-one-way-unification-when-resolving-traits/24483)
**Author:** [@osa1](https://internals.rust-lang.org/u/osa1)\ **Replies:** 1\ **Last updated:** [July 20, 2026, 4:50pm UTC](https://internals.rust-lang.org/t/two-way-vs-one-way-unification-when-resolving-traits/24483 "2026-07-20T16:50:21Z")
I'm trying to understand how trait resolving in the code below works: enum Wrap\ { W, WithVal(T), } struct Alt; trait Two\ {} impl\ Two\ for Wrap\ {} fn f\(p: P, q: Q) where P: Two\ {} fn m… --- ## [\[Pre-RFC\] Reborrow trait](https://internals.rust-lang.org/t/pre-rfc-reborrow-trait/22972)
**Author:** [@aapoalas](https://internals.rust-lang.org/u/aapoalas)\ **Replies:** 30\ **Last updated:** [July 19, 2026, 10:03am UTC](https://internals.rust-lang.org/t/pre-rfc-reborrow-trait/22972 "2026-07-19T10:03:01Z")
Well hello there! I'm soliciting for final feedback on the third draft of a Reborrow / "autoreborrow traits" RFC that I've been drawing up over the previous months. The RFC is up in my repository and the most recent ver… --- ## [Traits for function items](https://internals.rust-lang.org/t/traits-for-function-items/22815)
**Author:** [@alice](https://internals.rust-lang.org/u/alice)\ **Replies:** 16\ **Last updated:** [July 16, 2026, 6:57am UTC](https://internals.rust-lang.org/t/traits-for-function-items/22815 "2026-07-16T06:57:38Z")
Over the past few years, I've run into some convenience holes in the language related to function items, and I thought that some new traits could help here. The first trait could look like this: trait AsFunctionPointer… --- ## [\`cfg(extern = "rand")\`](https://internals.rust-lang.org/t/cfg-extern-rand/24470)
**Author:** [@epage](https://internals.rust-lang.org/u/epage)\ **Replies:** 5\ **Last updated:** [July 15, 2026, 11:30am UTC](https://internals.rust-lang.org/t/cfg-extern-rand/24470 "2026-07-15T11:30:56Z")
I don't have the time to drive this atm; I'm mostly posting as a place to reference the idea and in case anyone else wants to pick it up. Some cfg expressions can get complex or repetitive of specific data. cfg\_select! … --- ## [InteriorAssign trait { a := b }](https://internals.rust-lang.org/t/interiorassign-trait-a-b/24291)
**Author:** [@bluelightzero](https://internals.rust-lang.org/u/bluelightzero)\ **Replies:** 41\ **Last updated:** [July 14, 2026, 8:26pm UTC](https://internals.rust-lang.org/t/interiorassign-trait-a-b/24291 "2026-07-14T20:26:15Z")
There are already traits such as AddAssign to implement +=. It would be useful for code clarity if you could implement InteriorAssign to use :=. This could be used to sugar syntax such as this: data.ref\_cell.replace(S… --- ## [Too strict orphan rules E0117](https://internals.rust-lang.org/t/too-strict-orphan-rules-e0117/24221)
**Author:** [@PC-Killer](https://internals.rust-lang.org/u/PC-Killer)\ **Replies:** 5\ **Last updated:** [July 10, 2026, 7:15pm UTC](https://internals.rust-lang.org/t/too-strict-orphan-rules-e0117/24221 "2026-07-10T19:15:14Z")
Code: use std::collections::VecDeque; struct MyVec\(Vec\); impl\ From\\>\> for Option\\> { fn from(value: Option\\>) -\> Self { Some(MyVec(value?)) } } impl From\ **Author:** [@viruscamp](https://internals.rust-lang.org/u/viruscamp)\ **Replies:** 3\ **Last updated:** [July 8, 2026, 8:13am UTC](https://internals.rust-lang.org/t/an-experiment-lib-to-simulate-the-named-impl-draft/24434 "2026-07-08T08:13:04Z") An experiment lib to simulate the named impl draft viruscamp/rust-named-impl There are lots draft or post try to relax the orphan rule. One of them is my Draft: Named impl with Implementation Selection Variant. After ha… --- ## [Crowdsourcing request: What syntax changes that will affect the AST are currently in flight?](https://internals.rust-lang.org/t/crowdsourcing-request-what-syntax-changes-that-will-affect-the-ast-are-currently-in-flight/24361)
**Author:** [@ekuber](https://internals.rust-lang.org/u/ekuber)\ **Replies:** 9\ **Last updated:** [July 8, 2026, 6:02am UTC](https://internals.rust-lang.org/t/crowdsourcing-request-what-syntax-changes-that-will-affect-the-ast-are-currently-in-flight/24361 "2026-07-08T06:02:46Z")
During RustWeek I had a chance to catch up with dtolnay about moving default\_field\_values forward towards stabilization. One of the (mild) blockers is incorporating support for it in syn. To minimize strife, the idea wil… --- ## [Unsafe fields cannot define a correct moment to check conditions](https://internals.rust-lang.org/t/unsafe-fields-cannot-define-a-correct-moment-to-check-conditions/24436)
**Author:** [@Evian-Zhang](https://internals.rust-lang.org/u/Evian-Zhang)\ **Replies:** 12\ **Last updated:** [July 8, 2026, 1:06am UTC](https://internals.rust-lang.org/t/unsafe-fields-cannot-define-a-correct-moment-to-check-conditions/24436 "2026-07-08T01:06:08Z")
For unsafe methods, the safety requirements can be divided into exact two categories: requirements before invoking (Vec::set\_len requires new elements are initialized before this function), and requirements after invokin… --- ## [Typed keys as dyn-dispatchable method receivers](https://internals.rust-lang.org/t/typed-keys-as-dyn-dispatchable-method-receivers/24441)
**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")
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)
**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")
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… --- ## [Insecure fn](https://internals.rust-lang.org/t/insecure-fn/24435)
**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")
Hi, i request that feature because example let's have fn generate\_img\_src(url: String) -\> String { format!(r#"\"#, url) } that function is insecure because vulnerable to XSS, i propose something like … --- ## [Negative trait bounds using feature(specialization)](https://internals.rust-lang.org/t/negative-trait-bounds-using-feature-specialization/24412)
**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")
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… --- ## [A read only no alias reference](https://internals.rust-lang.org/t/a-read-only-no-alias-reference/24410)
**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")
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… --- ## [Err automatic hint::cold\_path?](https://internals.rust-lang.org/t/err-automatic-hint-cold-path/24404)
**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")
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)
**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")
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)
**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")
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… --- ## [\[Workable\] Selectable Named impl with Newtype Wrapper](https://internals.rust-lang.org/t/workable-selectable-named-impl-with-newtype-wrapper/24400)
**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")
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… --- ## [Infinite precision intermediate arithmetic: how much would break?](https://internals.rust-lang.org/t/infinite-precision-intermediate-arithmetic-how-much-would-break/24383)
**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")
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… [Previous page](https://internals.rust-lang.org/c/language-design/21.md) [Next page](https://internals.rust-lang.org/c/language-design/21.md?page=2)