HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rust-lang
rfcs
Markdown2014–2026
rust-lang / rfcs

rfcs

RFCs for changes to Rust

Explore on GitHubRead Hacker News discussions
352Distinct people
685Mentions
5Explicit recommenders
6.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

RFCs for changes to Rust

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

It is completely the answer to your question. Note that Rust does not have green threads (RFC 230: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...), so without…

halostatue used a recommendation phrase. 5 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

Rust 1.100 direct repository linkDebated

The discussion highlights significant new features in Rust 1.100, such as the stabilized never type and unused dependency warnings, while sparking a substantive debate over whether the language's lack of a stable ABI is a necessary trade-off for its generic system or an impediment to library distribution. Participants clash between those viewing the current source-only model as sufficient and those arguing that a native stable ABI is essential for practical binary interoperability.

66 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4

Mentions over time

HN mentions by year685 dated mentions

Observed mentions: 2014-04-09 12:17:16 UTC to 2026-08-22 09:34:08 UTC.

02550751002014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 50 mentions; 5 submissions, 45 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 87 mentions; 1 submissions, 86 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 105 mentions; 5 submissions, 100 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 81 mentions; 5 submissions, 76 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 64 mentions; 6 submissions, 58 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 41 mentions; 3 submissions, 38 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 63 mentions; 11 submissions, 52 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 46 mentions; 3 submissions, 43 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 38 mentions; 2 submissions, 36 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 44 mentions; 2 submissions, 42 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 31 mentions; 1 submissions, 30 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 22 mentions; 2 submissions, 20 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC50545
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC87186
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC1055100
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC81576
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC64658
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC41338
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC631152
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC46343
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC38236
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC44242
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC31130
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC22220
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC13013

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
Rust RFCs - RFC Book - Active RFC List The "RFC" (request for comments) process is intended to provide a consistent and controlled path for changes to Rust (such as new features) so that all stakeholders can be confident about the direction of the project. Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the Rust community and the sub-teams. Table of Contents Opening Table of Contents When you need to follow this process Sub-team specific guidelines Before creating an RFC What the process is The RFC life-cycle Reviewing RFCs Implementing an RFC RFC Postponement Help this is all too informal! License Contributions When you need to follow this process You need to follow this process if you intend to make "substantial" changes to Rust, Cargo, Crates.io, or the RFC process itself. What constitutes a "substantial" change is evolving based on community norms and varies depending on what part of the ecosystem you are proposing to change, but may include the following. Any semantic or syntactic change to the language that is not a bugfix. Removing language features, including those that are feature-gated. Large additions to std. Some changes do not require an RFC: Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not change meaning". Additions that strictly improve objective, numerical quality criteria (warning removal, speedup, better platform coverage, more parallelism, trap more errors, etc.) Additions only likely to be noticed by other developers-of-rust, invisible to users-of-rust. Minor additions to std: these only require an ACP. If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first. Sub-team specific guidelines For more details on when an RFC is required for the following areas, please see the Rust community's sub-team specific guidelines for: language changes, library changes, compiler changes. Before creating an RFC A hastily-proposed RFC can hurt its chances of acceptance. Low quality proposals, proposals for previously-rejected features, or those that don't fit into the near-term roadmap, may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother. Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project developers beforehand, to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building. The most common preparations for writing and submitting an RFC include talking the idea over on our official Zulip server, discussing the topic on our developer discussion forum, and occasionally posting "pre-RFCs" on the developer forum. You may file issues on this repo for discussion, but these are not actively looked at by the teams. As a rule of thumb, receiving encouraging feedback from long-standing project developers, and particularly members of the relevant sub-team is a good indication that the RFC is worth pursuing. What the process is In short, to get a major feature added to Rust, one must first get the RFC merged into the RFC repository as a markdown file. At that point the RFC is "active" and may be implemented with the goal of eventual inclusion into Rust. Fork the RFC repo RFC repository Copy 0000-template.md to text/0000-my-feature.md (where "my-feature" is descriptive). Don't assign an RFC number yet; This is going to be the PR number and we'll rename the file accordingly if the RFC is accepted. Fill in the RFC. Put care into the details: RFCs that do not present convincing motivation, demonstrate lack of understanding of the design's impact, or are disingenuous about the drawbacks or alternatives tend to be poorly-received. Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response. Now that your RFC has an open pull request, use the issue number of the PR to rename the file: update your 0000- prefix to that number. Also update the "RFC PR" link at the top of the file. Each pull request will be labeled with the most relevant sub-team, which will lead to its being triaged by that team in a future meeting and assigned to a member of the subteam. Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments. Feel free to reach out to the RFC assignee in particular to get help identifying stakeholders and obstacles. The sub-team will discuss the RFC pull request, as much as possible in the comment thread of the pull request itself. Offline discussion will be summarized on the pull request comment thread. RFCs rarely go through this process unchanged, especially as alternatives and drawbacks are shown. You can make edits, big and small, to the RFC to clarify or change the design, but make changes as new commits to the pull request, and leave a comment on the pull request explaining your changes. Specifically, do not squash or rebase commits after they are visible on the pull request. At some point, a member of the subteam will propose a "motion for final comment period" (FCP), along with a disposition for the RFC (merge, close, or postpone). This step is taken when enough of the tradeoffs have been discussed that the subteam is in a position to make a decision. That does not require consensus amongst all participants in the RFC thread (which is usually impossible). However, the argument supporting the disposition on the RFC needs to have already been clearly articulated, and there should not be a strong
Read the full README on GitHub

What Hacker News says

31 sources
brabel·Dec 1, 2024
Rust doesn't support that, but there's an RFC trying to figure out how that could be done (hasn't gone anywhere after more than 10 years of discussions): https://github.com/rust-lang/rfcs/issues/294 But Rust supports macros, just like Lisp, so of course someone wrote a library that provides something similar: https://docs.rs/some-error/latest/some_error/ Their post about how they came up with this crate is quite interesting: https://jam1.re/blog/anonymous-sum-types-for-rust-errors
In Rust Solves the Issues with Exceptions
pwdisswordfishz·Nov 6, 2024
> Pointers and references have the same layout. > The layout of a type is its size, alignment, and the relative offsets of its fields. So “layout” only constrains the memory addresses where a value and its constituents are stored; it does not cover niches. Pointers are allowed to be null, references are not. There is talk of making it illegal to have a reference be unaligned, or even point to very low addresses: <https://github.com/rust-lang/rfcs/pull/3204>. At one point, there was even talk of certain kinds of references not even being stored as memory addresses at all: <https://github.com/rust-lang/rfcs/pull/2040>. And Box<_> is not #[repr(transparent)] either. To put it more generally, the only semantics of a Box<_> or a reference is that it grants you access to a value of a given type and is inter-convertible with a pointer. Onl
Read the rest
y *const _ and *mut _ have a guaranteed ABI. Just because you write fewer “unsafe” keywords does not mean your code is more safe.
In Perhaps Rust Needs "Defer"
Arnavion·Oct 10, 2024
Rust has a generic assert too `assert!(foo >= bar);`. I assume (haven't used the crate myself) the advantage of `assertable::assert_ge!(foo, bar)` is that it prints the values of foo and bar in the assert message. The `assert_eq!(foo, bar)` and `assert_ne!(foo, bar)` macros provided by Rust libstd also do this. But the generic `assert!()` just sees the boolean result of its expression and only prints that in its message. The values of the variables can be included in the generic macro's message via a custom message format, like `assert!(foo >= bar, "foo = {foo}, bar = {bar}");` but having the macro do it by default is convenient. There is an old discussion to have the `assert!()` macro parse its expression to figure out what variables are there and print them out by default, but it's still WIP. ( https://github.com/rust-lang/rfcs/blob/mas
Read the rest
ter/text/2011-gene... https://github.com/rust-lang/rust/issues/44838 )
In Local Variables as Accidental Breadcrumbs for Faster Debugging
masklinn·Sep 8, 2024
That nobody has gone through the effort of collating its requirements and writing an RFC after https://github.com/rust-lang/rfcs/pull/770 was closed (back in 2015). I assume a big issue is that this is full of edge cases up the ass, and the value is somewhat limited in the sense that if you know you want durable writes you'll sync() and know you're fucked if you get an error, but close() does not guarantee a sync to disk, as the linux man page indicates: > A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes. So you'd need a "close", and a "close_sync", and possibly also a "close_datasync" (if you're ok with discarding metadata). And one could argue at that point `close` has essentially no value beyond hopefully getting rid of the fd / handle, and drop
Read the rest
already does a fine job of that.
In Don't defer Close() on writable files (2017)
lifthrasiir·Sep 4, 2024
I never heard of "German strings" in place of the small string optimization before! And there had been way too many proposals to add such types to the standard library [1] [2] [3] [4]. My understanding is that: 1. Both `Vec<u8>` and `String` should share the same layout as part of the standard library's contract. 2. Unlike `String`, the equivalent optimization for `Vec<T>` is more questionable especially when T might be any type. C++ standard libraries frequently do implement multiple layouts for std::string but not for std::vector<T> for the same reason. 3. Rust never allows an implicit copying of `String` in the first place, which greatly benefits from the SSO, so the lack of SSO in Rust is less important compared to C++. [1] https://github.com/rust-lang/rust/issues/4991 [2] https://github.com/rust-lang/rust/issues/20198 [3] https://git
Read the rest
hub.com/rust-lang/rfcs/pull/2990 [4] https://github.com/rust-lang/unsafe-code-guidelines/issues/4...
In An Optimization That's Impossible in Rust
vlovich123·Aug 29, 2024
Reasoning explained here: https://github.com/rust-lang/rfcs/blob/master/text/3173-floa... TLDR: no one really uses it, the spec is ambiguous and deprecated, and those that do use it seem to be using it with constants that are usually infinities which is better suited and clearer with next_up/next_down, and those that don’t use infinities tend to assume the range of the value and pick a constant outside the range which can be dangerous if the range changes
In Floating points between zero and one
Arnavion·Jul 29, 2024
Actually, Rust would also really like an `emplace_back`, because it does have the issue that `.push_back(Widget::new(foo, bar, baz))` can end up creating a Widget local in the caller and then moving it into the Vec allocation. It doesn't happen as much with optimizations enabled, but it does happen in debug builds. You might say "Big deal, it's just a tiny loss of performance to create a value and then copy it into its final place. Unlike C++ this is guaranteed to only do a copy of bytes, no complex code like a copy ctor. Who cares, especially if it's only noticeable in debug builds?" But it's not just a problem of performance. If it's `Box::new([0_u8; 10 * 1024 * 1024])`, then that 10 MiB array created in the caller's stack can end up blowing the caller's stack. Rust did actually try to add emplace style APIs and a dedicated operator. It
Read the rest
would've looked like `vec.place_back() <- Widget::new();` and it would've guaranteed that the generated code did not create a copy in the caller frame. It was never stabilized and instead eventually removed, because it was still not reliable enough to provide that guarantee after all. https://github.com/rust-lang/rfcs/blob/master/text/1228-plac... https://doc.rust-lang.org/1.26.0/std/vec/struct.Vec.html#met... https://github.com/rust-lang/rust/issues/27779#issuecomment-...
In Don't blindly prefer `emplace_back` to `push_back` (2021)

Showing the 15 most recent of 31 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.