Optimising `assert_eq` & `assert_ne` For running BorrowSanitizer on an assert_eq heavy test in Stringlet, I had to optimise it a lot. (I joined several into a single call assert_eq!((a1, a2, …), (b1, b2, …))). While trying to figure this out, VS code RA expand macro showed a pretty horrible, aka stemming from a time long before let-chains, implementation. I suggest the following solution, which in casual benchmarking compiles a multitude of these noticeably faster. Not sure if short-circuiting idents (to be more general, I tried path, but that had weird effects) improves this much. If so, a mirror of the 2nd branch would be needed. This is just a sketch, so I don’t show the variants with message. macro_rules! assert_eq { ($a:ident, $b:ident) => { assert!($s == $b); }; ($a:ident, $b:expr) => { if let b = &$b && !($a == *b) { panic!("ne"); } }; ($a:expr, $b:expr) => { if let (a, b) = &($a, $b) && !(*a == *b) { panic!("ne"); } }; } As I’m short on disk space, I don’t propose to create such a PR myself. I could flesh this out and just send the code half tested. 1 post - 1 participant Read full topic https://internals.rust-lang.org/t/optimising-assert-eq-assert-ne/24739 #stringlet #borrowsanitizer #rss #feeds #linksharing #qwibbit

Would it make sense for never to implement Iterator? After reading nightly documentation for the never type I started wondering why ! does not implement the Iterator trait. The documentation states: In general, if a trait only has methods taking a self parameter (or &self, or an argument of type Self, etc.), consider implementing it for ! Iterator trait meets this criterion. There is also an associated type, but the Not trait has an associated type as well and ! implements Not. In both cases ! seems like the most obvious choice for the item type. I tried implementing Iterator for an uninhabited enum and it looks like it should be possible for ! as well. enum Void {} impl Iterator for Void { type Item = Void; fn next(&mut self) -> Option { match *self {} // could also be None, but it does not matter, right? } } fn void_panic() -> Void { panic!() } fn my_foo() -> impl Iterator { void_panic() // error[E0271]: expected `Void` to be an iterator that yields `u32`, but it yields `Void` // instead of // error[E0277]: `Void` is not an iterator } fn main() { my_foo(); for x in void_panic() { // warning: unreachable expression // instead of // error[E0277]: `Void` is not an iterator } } Am I missing some potential problem? Is there a reason why ! does not implement Iterator 2 posts - 2 participants Read full topic https://internals.rust-lang.org/t/would-it-make-sense-for-never-to-implement-iterator/24732 #iterator #void #implementiterator #self #never #item #option #none #rss #feeds #linksharing #qwibbit

Yet Another Performance Footgun in Rust - Multithreading Lock Edition It turns out that RAII can lead to performance "footguns", not just regarding memory, but also with multithreading locks. The "holding a mutex longer than necessary" footgun. It’s easy to fall into this trap : { let data = data.lock() data.update(10) // ...lots of other code... } Oops, the mutex remains locked for the entire duration of the scope, even though it only needed to be held until the final write to the data variable. This degrades performance because other threads are forced to wait longer than they should. The performance hit, latency and throughput, scales linearly with the amount of code executed after the last write, the longer that code takes to reach the end of the scope, the more severe the latency increase and throughput drop become. This footgun appears frequently in real world code, as many developers write "vanilla" Rust without manually managing the lifetime of these locks. One might suggest calling drop explicitly or wrapping the logic in an inner scope, but neither is a robust or reliable solution. Why? Because both require manual awareness, in other words, they rely on the developer's skill to do so. By definition, a "footgun" is something that catches users off guard, often without them even realizing it. So, what is the solution? As it turns out, "ASAP drop" (dropping as soon as possible) can resolve not only memory related footguns but also performance issues stemming from multithreading locks. Visualization : let data = data.lock().unwrap() // `data` becomes a `MutexGuard` data.update(10) data.update(20) // The compiler analyzes when the `MutexGuard` is last used. // If the code above represents the final access, the compiler automatically inserts an unlock operation immediately afterward. // This allows other threads to take their turn without any unnecessary, prolonged waiting. data.unlock() // Inserted by the compiler As a further implementation guide, since read access is safe to perform from multiple threads, the unlock operation is inserted immediately after the final write, detected via &mut references, interior mutability, and raw mutable pointers (*mut). The final read access, using & and *const, does not extend the lifetime of the MutexGuard. This ensures that other threads get their turn as soon as possible, eliminating wasted time, resulting in low latency and high throughput right out of the box. 8 posts - 3 participants Read full topic https://internals.rust-lang.org/t/yet-another-performance-footgun-in-rust-multithreading-lock-edition/24726 #rust #footgun #mutexguard #rss #feeds #linksharing #qwibbit

Solving the problem of Cargo There is a very important rule if you want the manager is excellent for large tasks and huge projects such as OS, Game Engine, etc. One of the projects that require a very perfect manager, Cargo is beautiful, but doing things separately and mastering them is better than doing everything once weakly, so I want your suggestions for what may be improved in Cargo to solve this problem. 1 post - 1 participant Read full topic https://internals.rust-lang.org/t/solving-the-problem-of-cargo/24722 #cargo #gameengine #problem #rss #feeds #linksharing #qwibbit

This Week in Rust 675 Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR. Want TWIR in your inbox? Subscribe here. Updates from Rust Community Official Variadic Generics Micro Survey results How to fund Rust contributors Newsletters The Embedded Rustacean Issue #83 Project/Tooling Updates Ring Buffers Project Summary - Redox - Your Next(Gen) OS tar-codec: a fast and secure tar parser for the Rust ecosystem Observations/Thoughts Rust Without Shortcuts: What Safety Actually Costs What stable Rust stands on Where a Flood Goes Discussing a rewrite of XArray Rust features in the future Guidelines for panics in kernel code What distributed systems and end-to-end encrypted apps have in common? CRDTs and Rust! [video] P99 CONF 2026 | Building Ultra-Performant Message Streaming by Piotr Gankiewicz Rust Walkthroughs The heat is on: handling units in Rust Finding panics with Call Graph Analyzer [video] Beyond Vibe Coding: Formal Verification for AI-Generated Python & Rust Software [video] Rust and the GPU from Native to Web: An Introduction to wgpu by Liam Rust Miscellaneous [uz] Announcing Rust Uzbekistan & The Official Uzbek Translation of The Rust Book Crate of the Week This week's crate is offline-protocol, a crate that supplies mesh-networking/peer discovery for a variety of networks, under AGPL/proprietary license. Thanks to Gokul for the self-suggestion! Please submit your suggestions and votes for next week! Calls for Testing An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing. No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs. Let us know if you would like your feature to be tracked as a part of this list. Call for Participation; projects and speakers CFP - Projects Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. sysknife - SetSshdOption reports success while an earlier sshd_config.d drop-in overrides the value it wrote sysknife - On Postgres the daemon anchors the audit chain but every reader reports the anchor unsupported and exits 2 sysknife - ci-local.test.sh stays green when the #555 exit fix, the missing-tool default or the opt-out flag is reverted Tabularis - [Feat]: Import connections from pgAdmin 4 Keepword - Say how many networks have observed a node that isn't located yet Octomind - octomind workflow docs fails with "Is a directory" when ./docs/ exists Octomind - Workflow loop with max_iterations = 0 passes validation and never runs Octomind - ACP: send tool kind, file locations and diffs with tool calls If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon! CFP - Events Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker. If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon! Updates from the Rust Project 609 pull requests were merged in the last week Compiler account for missing turbofish in resolve errors add various #[inline] annotations for simple functions on hot paths that don't get inlined deduplicate DefId encodings in the query cache #[inline(always)] + #[target_feature(enable = "....")] #2 MIR move elimination [4/6]: MoveElimination rustc_builtin_macros cleanup, part 8 optimize Span operations, especially the hot Span::to skip redundant monomorphization checks use the span of the doctest code block fence for figuring out the line number Library const-stabilize {BinaryHeap, BTreeMap, BTreeSet, LinkedList, VecDeque)::{len, is_empty} core: implement char::is_xid_{start, continue} don't try to skip anything in Skip::advance_by(0) implement AsMut and AsRef for ! improve bit permutation codegen process: improve the output of Debug for ExitStatus on Unix stabilize ExitCodeExt for Windows stabilize allocators for Vec::into_iter stabilize String::into_chars stabilize ptr_cast_slice stabilize slice_split_once stabilize {Rc, Arc}::is_unique Cargo timings: peak memory as a column in unit table stop uplifting rlibs on nightly exclude abspath of path deps from -Cmetadata hash test: simplify file content assertions use build-rs for buildscripts Rustdoc include deprecated attributes in rustc_resolve intra-doc link resolution correctly handle inner deprecated attribute on modules don't panic on a nested use group with no path prefix Rustfmt prevent more comment loss in cfg_select! don't lose comments and attributes between cfg_select! predicates, outer/inner blocks, arm body and trailing commas fix cfg_if! error count leaks Clippy wildcard_imports: no longer lint in automatically derives and proc macro expansions add ifs_as_logical_ops lint add lint for map_or_else to map_or fix missing_const_for_fn false positives in const impl fix double_comparisons suggestion dropping required parentheses perf: optimise unconditional_recursion lint Rust-Analyzer automated sync of target feature implications fix NamedTempFile issues on windows complete 'main' 'lib' module in sub module compute ref-match on undotted self do not panic when inline call param usages in macro fix fetch_semantic logic bug introduced in #22272 fix status message for clients not supporting experimental/serverStatusNotification use absolute path in format_smolstr search manifest ancestors for the lockfile when fetching cargo metadata Rust Compiler Performance Triage Another week of positive changes. Few unexpected improvements from cleanups and a handful of targeted optimizations. Apart from instruction count improvements, we also merged a large reduction of query cache size in #164300. Negative changes come mostly from unexpected doc regression, which is currently under investigation. Triage done by @panstromek. Revision range: bd4c6cc4..019b59d8 Summary: (instructions:u) mean range count Regressions ❌ (primary) 0.8% [0.2%, 6.8%] 25 Regressions ❌ (secondary) 6.8% [0.0%, 189.1%] 34 Improvements ✅ (primary) -0.8% [-12.6%, -0.1%] 195 Improvements ✅ (secondary) -1.2% [-10.6%, -0.1%] 157 All ❌✅ (primary) -0.6% [-12.6%, 6.8%] 220 3 Regressions, 6 Improvements, 3 Mixed 32 artifact comparisons made in total Full report here Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: 2052-epochs.md: typo 3722-explicit-extern-abis.md: typo Fix libs nominated triagebot.toml Final Comment Period Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. Tracking Issues & PRs Rust Add let_underscore_drop_guard lint. Deprecate internal function vec::from_elem core: Add assert_matches and debug_assert_matches to the next prelude clarify when Vec::into_boxed_slice() is in-place Partially stabilize ptr_alignment_type as alignment_type std: make Instant a signed Duration on all platforms Lower #[no_mangle] to #[symbol_name]/#[link_name] lang team review for new trait solver Implement Fn traits for safe functions of any ABI cmse: lint on unions crossing the secure boundary Rust RFCs RFC: Add required-targets for workspace package selection Compiler Team (MCPs only) Add support for annotate-snippets's no-graphics output format No Items entered Final Comment Period this week for Cargo, Language Team, Language Reference or Unsafe Code Guidelines. Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list. New and Updated RFCs No New or Updated RFCs were created this week. Upcoming Events Rusty Events between 2026-10-28 - 2026-11-25 🦀 Virtual 2026-10-28 | Virtual (Cardiff, UK) | Rust and C++ Cardiff Operating Systems Book Club: Paging Mechanisms 2026-10-29 | Virtual | Rust 🦀 Maven Creating a hexadecimal editor in Rust 2026-11-01 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: First Sunday 2026-11-03 | Virtual | Rust 🦀 Maven Solving Real-World Planning Problems in Rust with SolverForge 2026-11-03 | Virtual (London, UK) | Women in Rust 👋 Community Catch Up 2026-11-04 | Virtual (Indianapolis, IN, US) | Indy Rust Indy.rs - with Social Distancing 2026-11-05 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-11-10 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Second Tuesday 2026-11-12 | Virtual (Nürnberg, DE) | Rust Nuremberg Rust Nürnberg online 2026-11-15 | Virtual | Rust 🦀 Maven Cursed Rust 2026-11-15 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Rust Deep Learning: Third Sunday 2026-11-17 | Virtual | Rust 🦀 Maven Miscompilation in Rust 1.97 2026-11-17 | Virtual (London, UK) | Women in Rust Lunch & Learn: The Harness Wore a Trenchcoat - Building a Rust MCP Server 2026-11-17 | Virtual (Washington, DC, US) | Rust DC Mid-month Rustful 2026-11-18 | Hybrid (Vancouver, CA) | Vancouver Rust Writing a firmware for Xteink ereader in Rust 2026-11-19 | Virtual (Berlin, DE) | Rust Berlin Rust Hack and Learn 2026-11-24 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup Fourth Tuesday Rust Bookclub Asia 2026-11-03 | Tel Aviv-Yafo, IL | Rust 🦀 TLV In person Rust November 2026 at AWS in Tel Aviv 2026-11-14 | Bengaluru, IN | Rust Bangalore November 2026 Rustacean Meetup Europe 2026-10-28 | Copenhagen, DK | Copenhagen Rust Community Rust meetup #72 sponsored by Google! 2026-10-29 | Berlin, DE | Rust Berlin Rust Berlin on location 🏳️‍🌈 – Edition 019 2026-10-31 | Stockholm, SE | Stockholm Rust Ferris' Fika Forum #31 2026-11-01 - 2026-11-03 | Italy, IN | RustLab RustLab - The International Conference on Rust in Italy 2026-11-02 | Berlin, DE | Rust Berlin Rust Berlin Talks: The next generation 2026-11-04 | Dublin, IE | Rust Dublin Rust 263: Getting Started with the New Rust Driver for Oracle AI Database 2026-11-05 | Milano, IT | Rust Language Milan Digital Model Trains & Rust: Bare-Metal DCC Command Station on ESP32 2026-11-05 | Oxford, UK | Oxford ACCU/Rust Meetup. Epitome of synaptic excellence 2026-11-12 | Geneva, CH | Rust Geneva Rust Meetup Geneva 2026-11-12 | Milano, MI, IT | Rust Language Milan From Curiosity to Capability: Build Your Own Device Swarm 2026-11-17 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig Everlock: Everything Is Git, Protocols Are Just Adapters 2026-11-19 | Aarhus, DK | Rust Aarhus Talk Night at EIVA North America 2026-10-28 | Austin, TX, US | Rust ATX Rust Lunch - Fareground 2026-10-31 | Boston, MA, US | Boston Rust Meetup North End Rust Lunch, Oct 31 2026-11-05 | Montréal, CA | Rust Montréal November Monthly Social 2026-11-05 | San Francisco, CA | Rust LA: NVIDIA NVIDIA x Lawrence Harvey | CUDA Rust 2026-11-05 | Saint Louis, MO, US | STL Rust HTMX and Rust 2026-11-12 | San Diego, CA, US | San Diego Rust San Diego Rust November Meetup - Back in person! 2026-11-14 | Boston, MA, US | Boston Rust Meetup MIT Rust Lunch, Nov 14 2026-11-17 | Los Angeles, CA, US | Rust Los Angeles Rust LA November w/ Hadrian! 2026-11-17 | San Francisco, CA, US | San Francisco Rust Study Group Rust Hacking in Person 2026-11-18 | Hybrid (Vancouver, CA) | Vancouver Rust Writing a firmware for Xteink ereader in Rust 2026-11-21 | Boston, MA, US | Boston Rust Meetup Winter Hill Rust Lunch, Nov 21 South America 2026-11-07 | Planalto Paulista, BR | Rust São Paulo Meetup Encontro do Rust-SP - Agora no Luma Oceania: 2026-11-24 | Barton, AU | Canberra Rust User Group November Meetup If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Jobs Please see the latest Who's Hiring thread on r/rust Quote of the Week we're at the 25 minute mark and still bikeshedding tabs vs spaces – Josh Triplett in a Library Team meeting Thanks to Theemathas for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell llogiq ericseppanen extrawurst U007D mariannegoldin bdillo opeolluwa bnchi KannanPalani57 tzilist Email list hosting is sponsored by The Rust Foundation Discuss on r/rust https://this-week-in-rust.org/blog/2026/10/28/this-week-in-rust-675/ #rss #feeds #linksharing #qwibbit

SAFETY comments - nomicon This, in an ongoing discussion on URLO, really hit home for me too. Jookia: Looking at the random crates I have downloaded, sdl3-sys, sdl3-rs, parley, fontations, they all use unsafe without a SAFETY quite a lot. std is even guilty of it, but seems to follow the suggestions here more. I tend to learn by doing or reading other people's work so this is where a source of my confusion comes from. I've also noticed that there are some excellent examples of SAFETY comments and many, very many, examples of unsafe with no comments. While agreeing with the OP, I thought "I'll refer to the nomicon, that will contain great guidelines on how to add SAFETY comments to code ..." - oops! The nomicon doesn't mention SAFETY comments once, nor safety-related lints While it does include inline comments in the "implementing Vec" example - they don't match today's expectations for format or content I'd like to suggest raising a PR to the nomicon to: add a dedicated section 1.4 "Documenting & auditing unsafe code" covering how to write safety comments as well as the fundamental rustc & clippy lints update the implementing Vec example to include exemplary safety documentation Given that we should expect a significant increase in the amount of unsafe being written in the next year, I'd consider now to be the right time to get ahead of this and hopefully push towards a positive feedback loop with more of that code including good comments. I'd be happy to work on this, but only if it has a chance of landing 2 posts - 2 participants Read full topic https://internals.rust-lang.org/t/safety-comments-nomicon/24721 #safetycomments #nomicon #vec #urlo #looking #documenting #rss #feeds #linksharing #qwibbit

Attempting to clean up the feature activation syntax? Currently, a feature activation in the manifest can include: "foo": activate the feature foo in the current package "dep:foo": activate the optional dependency foo "foo?/bar": if the optional dependency foo is activated, activate the feature bar within it "foo/bar": If foo is non-optional dependency, activate the feature "bar" within it If foo is an optional dependency, activate it, activate a feature named foo if present, and activate the feature bar On the command line with resolver = "2" or later, -F foo: activate foo within any selected packages that have it -F foo/bar If foo is a dependency of a selected package, treat foo/bar like it was in a manifest Else if foo is a workspace member, activate bar within it Problems with this It is hard to know what all these different forms are and their subtle meaning (e.g. I'm not sure that my summary is 100% accurate) Feels weird that -F foo/bar might not just activate bar but could also be equivalent of -F foo,foo/bar It is too easy to accidentally use "foo/bar" and pull in a dep and never realize it (Lint for suspicious optional dependency activation · Issue #17639 · rust-lang/cargo · GitHub) Processing "foo/bar" requires knowledge of the full manifest to know what it translates to (which caused us problems with the path we were taking on RFC #3491 which cause it to be pulled from the 2024 edition at the last minute) I've occasionally been confused that "foo?/bar" isn't "dep:foo?/bar" though from other perspectives, foo?/bar makes sense to me Additional context We are phasing out being able to refer directly to optional deps (RFC 3491) I have some other ideas for activating more non-feature items, like dep: does for dependencies So how should we clean this up? 3 posts - 2 participants Read full topic https://internals.rust-lang.org/t/attempting-to-clean-up-the-feature-activation-syntax/24718 #rss #feeds #linksharing #qwibbit

Impl mut and override for incremental, scoped reuse of existing impls Summary This proposal lets a downstream crate replace one method of an existing concrete impl while keeping the rest, via an opt-in impl mut marker and override blocks that forward unlisted methods to super. Concretely, it adds two new items: · impl mut Trait for Type { ... } marks an existing impl as open for override. · override Trait for Type { ... } creates a new implementation that only specifies the methods it changes; unlisted methods are implicitly forwarded to the override target. Inside an override block, super refers to the override target's implementation, allowing reuse of the original behavior. The goal is to let downstream crates incrementally modify an existing concrete impl without forking the crate, writing a newtype, or hand-writing forwarding boilerplate. Motivation Rust's existing reuse tools each have a gap: · Composition/delegation: Can modify behavior, but requires manually forwarding every method of the wrapped impl. Changing one method still means writing N forwarding stubs. · Newtype: Requires a new type; all signatures at call sites change. · Trait default methods: Reuse is decided by the trait author, not by the consumer; you cannot replace one method of an already written concrete impl. · Macros: Generate code, but the result is independent code with no semantic link to the original impl. · Specialization: Solves overlap at the generic constraint level, not "replace one method of a specific concrete impl and keep the rest." Concrete scenario: a third-party crate provides impl Parser for TheirType; one method has a bug or poor performance. Today the options are fork the crate, wrap it in a newtype and re-forward everything, or wait for upstream. There is no type-system-level way to say "use their impl, but replace this one method." This proposal is that mechanism. It is intentionally small: it does not change the default reuse path (traits + composition remain the norm), does not introduce inheritance trees, and does not pass implicit state between types. Detailed design impl mut — opt-in extension point. impl mut A for B { ... } declares the block open for override. A plain impl cannot be overridden. override — partial replacement with implicit forwarding.override A for B { fn foo(&self) { /* new behavior, may call super.foo() */ } // bar, baz, ... automatically forwarded to the override target } Only listed methods are replaced; unlisted methods forward to the override target. super — reuse the override target. super refers to the implementation named as the override target (the specific impl mut or override it was declared against), not a type hierarchy. super.foo() calls the target's foo. It appears in expression position inside override methods; super elsewhere remains the path keyword. Override chains form a DAG. override may target another override (see rule 6). Two overrides with the same target are allowed provided they are declared in different paths. super resolves along the declaration edge one step. Resolution scope is the declaration site. A call to T::method() inside a function resolves against the impls/overrides visible where the function is declared, not where it is called. This confines an override's effect to the declaring module and keeps coherence and monomorphization unaffected by call-site imports. Overrides are not re-overridable by default. An override can only be overridden if declared override mut. This mirrors the opt-in philosophy of impl mut. Orphan-rule exemption, disambiguated by paths. override is exempt from the orphan rule. Conflicts are resolved by import: use path::impl selects the base impl, use path::override selects an override. The same (Trait, Type) pair may not appear twice under one path. Missing mut recovery. If a downstream crate wants to override an override that was not marked mut, it copies that override into its own path and declares a fresh override. The new node is independent of the original; no special mechanism needed. Drawbacks · Trait resolution complexity. The resolver must incorporate "overrides visible at the declaration site" into trait solving. This is the main engineering cost; rule 5 deliberately fixes the scope to keep it bounded. · Readability of chains. With a DAG and implicit forwarding, "which impl actually runs" needs tooling (e.g., an override-chain expansion). This is a tooling concern, not a semantic one. · Proliferation risk. Authors may mark every impl mut "just in case," diluting the meaning of the extension point. A lint or community convention could mitigate this. Rationale and alternatives · Why not specialization? Specialization decides overlap among impls with different generic bounds; it does not let a consumer replace one method of a specific concrete impl while retaining the rest. The two are complementary. · Why not scope-based impl selection? Scoped-impl proposals address orphan-rule bypass and impl selection per scope, and typically change the type's identity. This proposal keeps type identity and adds incremental modification with super reuse. · Why impl mut rather than "any impl is overridable"? Opt-in prevents third parties from silently altering a library's behavior; the library author decides whether an extension point exists. Prior art I am not aware of an accepted or open RFC matching this combination (impl mut + partial override + super reuse + declaration-site resolution). Scope-based impl proposals share the "disambiguate by path" idea but differ in purpose and semantics. Feedback on closer prior art is welcome — that is part of why this is a Pre-RFC. Unresolved questions Keyword collision for super. super currently only appears in paths, and an override block's method body is an expression context, so the two usages likely do not collide syntactically. Preferred: keep super, resolved by context. Fallback if the parser or diagnostics object: a contextual keyword base, valid only inside override blocks. Naming. Should impl mut / override blocks be optionally nameable for better diagnostics and path imports, without forcing authors to pick names? Path-syntax ergonomics. Is use path::impl / use path::override acceptable, or does it need a dedicated syntax? Interaction with specialization and coherence. Does declaration-site resolution fully avoid interaction with the existing coherence model, or are there edge cases (e.g., associated type projection through an override)? Associated types. The sketch allows associated types to be overridden; projection through an override chain needs specification. Object safety and dyn. How do overrides interact with trait objects and vtable construction? Conclusion This is a small mechanism aimed at a specific gap: modifying an existing concrete impl incrementally, in a way that is explicit, scoped, and reuses the original via super. It does not replace composition or traits as the default reuse path. I am posting this as a Pre-RFC to validate that the gap is real, check for prior art, and get feedback on the resolution-scope question and the DAG semantics before considering a formal RFC. Disclosure: The design and core ideas are mine. The English text of this post was drafted with AI assistance. 4 posts - 3 participants Read full topic https://internals.rust-lang.org/t/impl-mut-and-override-for-incremental-scoped-reuse-of-existing-impls/24708 #override #impl #mut #existing #reuse #trait #type #requires #composition #rss #feeds #linksharing #qwibbit

How to fund Rust contributors TLDR: To fund general maintenance, donate to the Rust Foundation Maintainers Fund or sponsor the RustNL Maintainers Team To fund specific features and improvements, sponsor fundable Rust Project Goals To fund individual contributors, donate to their GitHub Sponsors accounts There is always so much to do in the Rust Project! New features to implement, bugs to fix, performance optimizations to make, issues to triage… It takes a lot of work to keep our high bar of quality while also shipping new features and improvements. And the workload keeps increasing with the continuous growth of Rust adoption. As is unfortunately common in open source projects, a large fraction of that work is currently done by volunteers. That causes various issues, such as people burning out or complex features taking many years to ship. Unsurprisingly, one of the best ways to help improve that is to get more people who work on Rust funded! This year, several funding initiatives started ramping up, and we already experience many positive effects. They helped us improve the maintenance status of critical Rust projects and make significant progress on several long-awaited features, such as allocators, the never type, the next trait solver or the Polonius borrow checker. However, only a fraction of people working on Rust are currently funded for their work. We know that there are Rust users, both individuals and companies, who would like to help improve Rust by funding it, but it might not always be obvious how exactly to do that. This post thus provides suggestions on how you can support the development of Rust in three ways. If you're unsure which option fits, or would like to discuss funding on behalf of your company, please contact the Funding team. Fund general maintenance Maintenance is a continuous process required to keep Rust (or any software project for that matter) working. It consists of two main activities. The first is general housekeeping, such as ensuring that Continuous Integration works, dependencies are kept up-to-date and issues, bugs and security incidents are promptly triaged and resolved. The second is performing refactorings and code reviews, which ensures that the codebase will be able to evolve and continuously ship new features, without accruing extensive technical debt. Having quality maintenance is crucial for the long-term health of Rust, yet it is typically very difficult to find funding for it; funders often want to sponsor specific new features, rather than just "keeping the lights on". However, without sufficient maintenance, it becomes much more difficult, and much slower, to ship new features. Improving the maintenance of Rust thus also helps us ship features and improvements faster, though the effects are sometimes only observable over longer periods of time. Funding maintenance is a great choice if you want to let us decide how best to improve Rust. The Rust Funding team continuously looks for Rust teams and projects that require help with their maintenance efforts, and allocates available funds to Rust maintainers who could help improve the situation. To fund Rust maintainers, consider donating to the Rust Foundation Maintainers Fund or sponsoring the RustNL Maintainers Team. Fund specific features and improvements There are always many Rust improvements and new features that are in progress. We track some of those initiatives through Rust Project Goals. Each Goal describes a specific improvement to Rust: what it is, who is going to develop and drive it forward and which Rust teams are willing to help reviewing and maintaining it. Some of those Goals are looking for funding. Either to help their owner dedicate time and focus to push the given feature forward, or to fund maintainers who will perform refactorings necessary to unblock that feature and review its implementation. Often funding is required for both. When a Goal is properly funded, the probability that it will achieve its milestones is much higher, which then translates in the given improvement being shipped sooner to Rust users. Funding Project Goals is a great choice if you want to help push forward specific Rust features or Rust toolchain improvements that will benefit you or your company. To fund contributors working on Project Goals, consider taking a look at Goals that need funding and reaching out to their funding contact. If in doubt how to proceed, reach out to the Rust Funding team. Fund individual contributors There are hundreds of people in the Rust Project who continuously work on improving Rust. Some of them have personal fundraising profiles (e.g. on GitHub Sponsors), which allows you to support them directly. There might be various reasons for supporting a specific person. Maybe they are maintaining a crate that you love to use, maybe you like reading their blog posts, or maybe you are simply a fan of the work that they do. Whatever the reason, we are sure that they would appreciate your support! Funding individual contributors is a great choice if you want to directly support Rust contributors whose work you appreciate. To fund individual Rust contributors, check out their GitHub profile or personal website to see what options there are for supporting them. You can also examine our list of Rust Project members who can be supported through GitHub Sponsors[1]. Conclusion We hope that this post is useful to anyone who would potentially like to invest funds into making Rust better. You can also find a shortened version of the "how to fund Rust guide" at the Funding page of the Rust website, or check out a RustConf 2026 talk by Niko Matsakis about how Project Goals and their funding works. If you are a company looking to fund the development of Rust, consider joining the Rust Commercial Network. Joining the network is free, and Rust Foundation membership is not required. It can help you find opportunities for funding improvements in specific areas related to Rust usage (e.g. user interfaces, language interop, supply chain security, etc.) and collaborate on funding Rust development with other companies. There are of course other ways of helping Rust other than donating funds. For example, you can check out Project Goals that are looking for contributors or more generally check our contributor onboarding guide. Companies can also help by giving employees paid time to contribute upstream, or by hiring Rust contributors to do that work. One possible model is the Engineer in Residence role, that was recently established in the Rust Foundation. Note that this list is not exhaustive; there are some Project members who accept donations through GitHub Sponsors (or another fundraising platform), but did not opt into being listed on this page. ↩ https://blog.rust-lang.org/2026/10/26/how-to-fund-rust-contributors/ #rust #rustproject #maintenance #maintainersfund #rustfoundation #funding #contributors #projectgoals #team #rustnlmaintainers #rss #feeds #linksharing #qwibbit

Why `.insert_entry()` is private for `HashSet` and `BTreeSet` Entry APIs? VacantEntry and Entry of HashMap and BTreeMap each have a method called .insert_entry(). Methods with this name also exist in the nightly-only experimental Entry APIs of HashSet and BTreeSet. However, these are private, so they can't be called by downstream programmers. Is there a reason for this difference in APIs, or is this just an accidental inconsistency? 2 posts - 2 participants Read full topic https://internals.rust-lang.org/t/why-insert-entry-is-private-for-hashset-and-btreeset-entry-apis/24710 #entry #btreeset #apis #hashset #methods #however #rss #feeds #linksharing #qwibbit