I hope that when building Vec through vec! macros, I can expand other arrays and make their elements part of the array, simplifying code writing. The example code is as follows: let a = vec![3, 4]; let b = vec![5, 6]; let c = vec![1, 2, ...a, ...b]; // then c = [1, 2, 3, 4, 5, 6]| Rust Internals - Latest posts
Suddenly I see nightly/unstable/experimental API at/under std - Rust. It used to be only at/under Rust Documentation or Rust Documentation. Is this intentional? UseCloned in std::clone - Rust - this DOES have #[unstable(...)] in source: clone.rs - source use - Rust (I didn't check the source) pointer - Rust (I didn't check the source)| Rust Internals - Latest posts
This is a reasonable suggestion but doesn't seem to have generated much enthusiasm. As initial feedback, here are some considerations that should be addressed. How would doc strings on implementations get merged? /// A `Foo` does this #[doc(merge)] impl Foo {...} /// A `Foo` does that #[doc(merge)] impl Foo {...} What should be the behavior if some merged impl's contain where clauses or other generic type variations. #[doc(merge)] impl<T> Foo<T> {...} #[doc(merge)] impl<T> Foo<T> where T: Clo...| Rust Internals - Latest posts
The 1.91.0 pre-release is ready for testing. The release is scheduled for October 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 update stable The index is https://dev-static.rust-lang.org/dist/2025-10-27/index.html. The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.| Rust Internals - Latest posts
I would be strongly opposed to such a change. I have seen (in C++) implicit casts cause bugs in both narrowing and widening directions. At my day job (where we still have C++) we use tooling to forbid all implicit casts.| Rust Internals - Latest posts
Supposedly it is a project goal. Which must count for something. Visible progress seems extremely slow though.| Rust Internals
As we all know, panic in Rust is a quite serious problem, we will do everything we can to avoid it. i.e., no unwrap ... etc. force developer to deal with all situations. But I ran into a panic which really surprises me. Basically: let x: uint = 8; let y: uint = 9; I meant to compare: if x < y { } ,which works fine. but the other day, for some reason, I wrote: if x - y < 0 {} And the system simply panics. I know why it panics, but I really feel rust compiler should somehow prevent me from maki...| Rust Internals - Latest posts
I think you're referring to the glibc Hardware capabilities section in ld.so(8) which will additionally search glibc-hwcaps/$subarch in each search path directory first to load hwcap-aware builds of libraries.| Rust Internals - Latest posts
This is a pretty obvious topic so I searched around, but this has apparently not been discussed for at least 6 years, and as far as I can tell the reason the discussions stopped is that they got distracted and then forgotten. So, I think it's appropriate to bring it up again with a stricter scope, providing as much specific reasoning as I can. I guess this is a pre-RFC, but I'm new to this. Rust's lack of implicit numeric coercions prevents unexpected precision loss and forces conversions to ...| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
One option here is that cargo's release profile could default to a higher version than the target's baseline. That's admittedly easier said than done but it would solve the tension between "this is the absolute minimum we support" and "this is what 99% of people probably want".| Rust Internals
Has a feature of conditional compilation during monomorphisation been considered? I'd like to compile something like this: fn blah(a: A) { #[conditional(A: Debug)] debug!("blah called with {:?}", a); #[conditional(A: !Debug)] debug!("blah called with a value of type {}", type_name::); } This is a form of specialization, but more compact, and flexible to some extent| Rust Internals
As an update on our CI evaluation process - we are transitioning rust-lang/rust’s CI from Travis CI to Microsoft’s Azure Pipelines. This is the result of a generous sponsorship offer from the Azure Pipelines team. This pipeline has been in the testing process for several weeks and we expect to use it to prepare the 1.37 release. We are still in the process of fine-tuning the results, but we expect to make a more complete (and more public) announcement in due time. We’re still working wi...| Rust Internals
New blog post: Towards a Rust foundation Summary In my #rust2020 blog post, I mentioned rather off-handedly that I think the time has come for us to talk about forming a Rust foundation. I wanted to come back to this topic and talk in more detail about what I think a Rust foundation might look like. And, since I don't claim to have the final answer to that question by any means, I'd also like to talk about how I think we should have this conversation going forward. Hat tip As the post notes...| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Summary This is a pre-RFC for a indentation field for the FormattingOptions struct in std::fmt that is used for giving directives to Formatter objects. A brief Github search for write!(f, "\t returns 7.6k results, which makes me believe the use case I had in mind, which is writing printers for recursive structures, is not that uncommon. While printing recursive structures, the typical mechanism is to pass a depth that can be used to decide what the indentation should be. If FormattingOptions....| Rust Internals - Latest posts
I tend to be curious about language design topics that have some discussion around them, like variadics, keyword generics, or undroppable types, but I never came across discussion about trait generics. Has there been any proposals for it? Are there clear downsides I'm missing? Is this just an irrelevant feature for most users? I ask because recently I caught myself searching if the Either type, from the either crate, implemented Iterator when both the Left and Right parameters implemented it ...| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Feature Name: substructural_traits Start Date: 10-11-2025 RFC PR: rust-lang/rfcs#0000 Rust Issue: rust-lang/rust#0000 Summary Rust has parts of a substructural type system, but it is incomplete. A substructural type system is extremely important to correctly capture the behavior of real computer systems in the absence of garbage collection and presence of non-memory resources. As Rust has grown, the incomplete nature of Rust’s substructural type system has caused more and more problems, suc...| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
struct Foo {} impl Foo { fn to_bar(&self, maybe: bool) -> Option> { maybe.then(|| Box::new(0usize)) } } impl Bar for usize {} trait Bar {} This is the kind of thing that I'd usually expect to work, but it fails: rror[E0308]: mismatched types --> src/lib.rs:5:9 | 4 | fn to_bar(&self, maybe: bool) -> Option> { | -------------------- expected `Option>` because of return type 5 | ...| Rust Internals
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() { let mut s = "hi there".to_owned(); s.drain(2..6); println!("{s}"); } I'm quite surprised by this. It is of course perfectly fine to drop Drain type. Unless it is forgotten there is no memory leak, so the only consequence of dropping it is that drained items are dropped as ...| Rust Internals
(Most recent version on GitHub) Feature Name: abi_aarch64_indirect_return Start Date: 2025-08-24 RFC PR: rust-lang/rfcs#0000 Rust Issue: rust-lang/rust#0000 Summary Introduce a new target-specific calling convention aarch64-indirect-return, which will pass the first argument as if it was an indirect result location pointer (that is, through the x8 register). This would make it possible for Rust to interoperate with C++ functions that return non-trivial C++ objects on aarch64. Motivation Cur...| Rust Internals
there's a lot of arguments for and against this, but i think a lot of these don't matter, because many crates are already shipping prebuilt artifacts. ideally this could also be integrated with some sort of deterministic build system. the simplest implementation would be a per-crate (not per package) table that maps a target triple and a rust version (may be ignored for crates with a stable ABI or ones that are cli-only) to a hash and url for that crate's output. may need another layer of nes...| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
Discussions around the design and implementation of The Rust Programming Language| Rust Internals
I’ve been posting a bunch of blog posts on dyn async in traits. I just realized I never made an internals thread to discuss them! Fixed. Part 1 Part 2 Part 3 Part 4 Part 5| Rust Internals
In my last post, I talked about the new “pinned references” which guarantee that the data at the memory it points to will not, ever, be moved elsewhere. I explained how they enable giving a safe API to code that could previously only be exposed with unsafe, and how one could go about proving such a thing. This post is about another application of pinned references—another API whose safety relies on the pinning guarantees: Intrusive collections. It turns out that pinned references can al...| Rust Internals
Recently, a new API for “pinned references” has landed as a new unstable feature in the standard library. The purpose of these references is to express that the data at the memory it points to will not, ever, be moved elsewhere. Others have written about why this is important in the context of async IO. The purpose of this post is to take a closer, more formal look at that API: We are going to take a stab at extending the RustBelt model of types with support for pinning. https://www.ralfj...| Rust Internals
RFC 2349 proposing a new set of APIs to deal with types that cannot be safely moved around - especially generators and async functions. You can read more details of the design in the RFC. This thread is a sidebar to discuss the names of these types. The names proposed in the RFC were arrived at ‘evolutionarily’ as several different previous APIs converged into the present one. So they’re not necessarily very good. The relationship between the three items (review of the RFC) The trait Mo...| Rust Internals
Secretly and behind the scenes more and more Rust code lives a life before main. What is life before main? It's code that executes before the rust runtime has been initialized in main. This is something that Rust does not support but because the world needs to support C++ static initializers and __attribute__((constructor)) in C, it's also possible to get Rust code to execute this way. The popular crate for this is ctor. Using it is probably not a great idea, but unfortunately there are lots ...| Rust Internals