We are happy to announce that the third edition of the Rust language, Rust 2021, is scheduled for release in October. Rust 2021 contains a number of small changes that are nonetheless expected to make a significant improvement to how Rust feels in practice.
The release of Rust 1.0 established"stability without stagnation"as a core Rust deliverable. Ever since the 1.0 release, the rule for Rust has been that once a feature has been released on stable, we are committed to supporting that feature for all future releases.
There are times, however, when it is useful to be able to make small changes
to the language that are not backwards compatible.
The most obvious example is introducing a new keyword,
which would invalidate variables with the same name.
For example, the first version of Rust did not have the async
and await
keywords.
Suddenly changing those words to keywords in a later version would've broken code like let async = 1;
.
Editions are the mechanism we use to solve this problem.
When we want to release a feature that would otherwise be backwards incompatible,
we do so as part of a new Rust edition.
Editions are opt-in, and so existing crates do
not see these changes until they explicitly migrate over to the new edition.
This means that even the latest version of Rust will still not treat async
as a keyword,
unless edition 2018 or later is chosen.
This choice is made per crateas part of its Cargo.toml
.
New crates created by cargo new
are always configured to use the latest stable edition.
The most important rule for editions is that crates in one edition can interoperate seamlessly with crates compiled in other editions. This ensures that the decision to migrate to a newer edition is a "private one" that the crate can make without affecting others.
The requirement for crate interoperability implies some limits on the kinds of changes that we can make in an edition. In general, changes that occur in an edition tend to be "skin deep". All Rust code, regardless of edition, is ultimately compiled to the same internal representation within the compiler.
Our goal is to make it easy for crates to upgrade to a new edition.
When we release a new edition,
we also provide tooling to automate the migration.
It makes minor changes to your code necessary to make it compatible with the new edition.
For example, when migrating to Rust 2018, it changes anything named async
to use the equivalentraw identifier syntax: r#async
.
The automated migrations are not necessarily perfect: there might be some corner cases where manual changes are still required. The tooling tries hard to avoid changes to semantics that could affect the correctness or performance of the code.
In addition to tooling, we also maintain an Edition Migration Guide that covers the changes that are part of an edition. This guide will describe the change and give pointers to where people can learn more about it. It will also cover any corner cases or details that people should be aware of. The guide serves both as an overview of the edition, but also as a quick troubleshooting reference if people encounter problems with the automated tooling.
Over the last few months, the Rust 2021 Working Group has gone through a number of proposals for what to include in the new edition. We are happy to announce the final list of edition changes. Each feature had to meet two criteria to make this list. First, they had to be approved by the appropriate Rust team(s). Second, their implementation had to be far enough along that we had confidence that they would be completed in time for the planned milestones.
The prelude of the standard libraryis the module containing everything that is automatically imported in every module.
It contains commonly used items such as Option
, Vec
, drop
, and Clone
.
The Rust compiler prioritizes any manually imported items over those
from the prelude, to make sure additions to the prelude will not break any existing code.
For example, if you have a crate or module called example
containing a pub struct Option;
,
then use example::*;
will make Option
unambiguously refer to the one from example
;
not the one from the standard library.
However, adding a trait to the prelude can break existing code in a subtle way.
A call to x.try_into()
using a MyTryInto
trait might become ambiguous and
fail to compile if std
's TryInto
is also imported,
since it provides a method with the same name.
This is the reason we haven't added TryInto
to the prelude yet,
since there is a lot of code that would break this way.
As a solution, Rust 2021 will use a new prelude. It's identical to the current one, except for three new additions:
Since Rust 1.51.0, Cargo has opt-in support for a new feature resolverwhich can be activated with resolver = "2"
in Cargo.toml
.
Starting in Rust 2021, this will be the default.
That is, writing edition = "2021"
in Cargo.toml
will imply resolver = "2"
.
The new feature resolver no longer merges all requested features for crates that are depended on in multiple ways. See the announcement of Rust 1.51 for details.
Until Rust 1.53, only references to arrays implement IntoIterator
.
This means you can iterate over &[1, 2, 3]
and &mut [1, 2, 3]
,
but not over [1, 2, 3]
directly.
for &e in &[1, 2, 3] {} // Ok :)
for e in [1, 2, 3] {} // Error :(
This has been a long-standing issue, but the solution is not as simple as it seems.
Just adding the trait implementation would break existing code.array.into_iter()
already compiles today because that implicitly calls(&array).into_iter()
due to how method call syntax works.
Adding the trait implementation would change the meaning.
Usually we categorize this type of breakage (adding a trait implementation) 'minor' and acceptable. But in this case there is too much code that would be broken by it.
It has been suggested many times to "only implement IntoIterator
for arrays in Rust 2021".
However, this is simply not possible.
You can't have a trait implementation exist in one edition and not in another,
since editions can be mixed.
Instead, we decided to add the trait implementation in all editions (starting in Rust 1.53.0),
but add a small hack to avoid breakage until Rust 2021.
In Rust 2015 and 2018 code, the compiler will still resolve array.into_iter()
to (&array).into_iter()
like before, as if the trait implementation does not exist.
This only applies to the .into_iter()
method call syntax.
It does not affect any other syntax such as for e in [1, 2, 3]
, iter.zip([1, 2, 3])
orIntoIterator::into_iter([1, 2, 3])
.
Those will start to work in all editions.
While it's a shame that this required a small hack to avoid breakage, we're very happy with how this solution keeps the difference between the editions to an absolute minimum. Since the hack is only present in the older editions, there is no added complexity in the new edition.
Closuresautomatically capture anything that you refer to from within their body.
For example, || a + 1
automatically captures a reference to a
from the surrounding context.
Currently, this applies to whole structs, even when only using one field.
For example, || a.x + 1
captures a reference to a
and not just a.x
.
In some situations, this is a problem.
When a field of the struct is already borrowed (mutably) or moved out of,
the other fields can no longer be used in a closure,
since that would capture the whole struct, which is no longer available.
let a = SomeStruct::new();
drop(a.x); // Move out of one field of the struct
println!("{}", a.y); // Ok: Still use another field of the struct
let c = || println!("{}", a.y); // Error: Tries to capture all of `a`
c();
Starting in Rust 2021, closures will only capture the fields that they use. So, the above example will compile fine in Rust 2021.
This new behavior is only activated in the new edition,
since it can change the order in which fields are dropped.
As for all edition changes, an automatic migration is available,
which will update your closures for which this matters.
It can insert let _ = &a;
inside the closure to force the entire
struct to be captured as before.
The panic!()
macro is one of Rust's most well known macros.
However, it has some subtle surprisesthat we can't just change due to backwards compatibility.
panic!("{}", 1); // Ok, panics with the message "1"
panic!("{}"); // Ok, panics with the message "{}"
The panic!()
macro only uses string formatting when it's invoked with more than one argument.
When invoked with a single argument, it doesn't even look at that argument.
let a = "{";
println!(a); // Error: First argument must be a format string literal
panic!(a); // Ok: The panic macro doesn't care
(It even accepts non-strings such as panic!(123)
, which is uncommon and rarely useful.)
This will especially be a problem onceimplicit format argumentsare stabilized.
That feature will make println!("hello {name}")
a short-hand for println!("hello {}", name)
.
However, panic!("hello {name}")
would not work as expected,
since panic!()
doesn't process a single argument as format string.
To avoid that confusing situation, Rust 2021 features a more consistent panic!()
macro.
The new panic!()
macro will no longer accept arbitrary expressions as the only argument.
It will, just like println!()
, always process the first argument as format string.
Since panic!()
will no longer accept arbitrary payloads,panic_any()
will be the only way to panic with something other than a formatted string.
In addition, core::panic!()
and std::panic!()
will be identical in Rust 2021.
Currently, there are some historical differences between those two,
which can be noticable when switching #![no_std]
on or off.
To make space for some new syntax in the future,
we've decided to reserve syntax for prefixed identifiers and literals:prefix#identifier
, prefix"string"
, prefix'c'
, and prefix#123
,
where prefix
can be any identifier.
(Except those that already have a meaning, such as b'…'
and r"…"
.)
This is a breaking change, since macros can currently accept hello"world"
,
which they will see as two separate tokens: hello
and "world"
.
The (automatic) fix is simple though. Just insert a space: hello "world"
.
Other than turning these into a tokenization error,the RFC does not attach a meaning to any prefix yet. Assigning meaning to specific prefixes is left to future proposals, which will—thanks to reserving these prefixes now—not be breaking changes.
These are some new prefixes you might see in the future:
f""
as a short-hand for a format string.f"hello {name}"
as a short-hand for the equivalent format_args!()
invocation.c""
or z""
for null-terminated C strings.k#keyword
to allow writing keywords that don't exist yet in the current edition.async
is not a keyword in edition 2015,k#async
as an alternative in edition 2015async
as a keyword.Two existing lints are becoming hard errors in Rust 2021. These lints will remain warnings in older editions.
bare-trait-objects
:dyn
keyword to identify trait objectswill be mandatory in Rust 2021.ellipsis-inclusive-range-patterns
:...
syntaxfor inclusive range patterns is no longer accepted in Rust 2021...=
, which is consistent with expressions.Starting in Rust 1.53.0, patternsare extended to support |
nested anywhere in the pattern.
This enables you to write Some(1 | 2)
instead of Some(1) | Some(2)
.
Since this was simply not allowed before, this is not a breaking change.
However, this change also affects macro_rules
macros.
Such macros can accept patterns using the :pat
fragment specifier.
Currently, :pat
does not match |
, since before Rust 1.53,
not all patterns (at all nested levels) could contain a |
.
Macros that accept patterns like A | B
,
such as matches!()
use something like $($_:pat)|+
.
Because we don't want to break any existing macros,
we did not change the meaning of :pat
in Rust 1.53.0 to include |
.
Instead, we will make that change as part of Rust 2021.
In the new edition, the :pat
fragment specifier will match A | B
.
Since there are times that one still wishes to match a single pattern
variant without |
, the fragment specified :pat_param
has been added
to retain the older behavior.
The name refers to its main use case: a pattern in a closure parameter.
Our plan is to have these changes merged and fully tested by September, to make sure the 2021 edition makes it into Rust 1.56.0. Rust 1.56.0 will then be in beta for six weeks, after which it is released as stable on October 21st.
However, note that Rust is a project run by volunteers. We prioritize the personal well-being of everyone working on Rust over any deadlines and expectations we might have set. This could mean delaying the edition a version if necessary, or dropping a feature that turns out to be too difficult or stressful to finish in time.
That said, we are on schedule and many of the difficult problems are already tackled, thanks to all the people contributing to Rust 2021! 💛
You can expect another announcement about the new edition in July. At that point we expect all changes and automatic migrations to be implemented and ready for public testing.
We'll be posting some more details about the process and rejected proposals on the "Inside Rust" blog soon. (Correction: This did not end up happening due to lack of bandwidth)
The Rust team has prepared a new release, 1.52.1, working around a bug in incremental compilation which was made into a compiler error in 1.52.0. We recommend all Rust users, including those currently using stable versions prior to 1.52.0, upgrade to 1.52.1 or disable incremental compilation. Guidance on how to do so is available below.
If you have a previous version of Rust installed via rustup, getting Rust 1.52.1 is as easy as:
rustup update stable
If you don't have it already, you can get rustup
from the appropriate page on our website.
This release works around broken builds on 1.52.0, which are caused by newly added verification. The bugs this verification detects are present in all Rust versions1, and can trigger miscompilations in incremental builds, so downgrading to a prior stable version is not a fix.
Users are encouraged to upgrade to 1.52.1 or disable incremental in their local environment if on a prior version: please see the what you should dosection for details on how to do so.
Incremental compilation is off by default for release builds, so few production builds should be affected (only for users who have opted in).
Miscompilations that can arise from the bugs in incremental compilation generate incorrect code in final artifacts, essentially producing malformed binaries, which means that in theory any behavior is possible. In practice we are currently only aware of one particular known miscompilation, but bugs due to incremental are notoriously hard to track down: users frequently simply rebuild after some light editing if they see unexpected results from their binaries, and this often causes sufficient recompilation to fix the bug(s).
This post is going to:
The error message looks something like this, with the key piece being the "found unstable fingerprints" text.
thread 'rustc' panicked at 'assertion failed: `(left == right)`
left: `Some(Fingerprint(4565771098143344972, 7869445775526300234))`,
right: `Some(Fingerprint(14934403843752251060, 623484215826468126))`: found unstable fingerprints for <massive text describing rustc internals elided>
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
This is the error caused by the internal consistency check, and as stated in the diagnostic, it yields an "Internal Compiler Error" (or ICE). In other words, it represents a bug in the internals of the Rust compiler itself. In this case, the ICE is revealing a bug in incremental compilation that predates the 1.52.0 release and could result in miscompilation if it had not been caught.
The Rust compiler has support for "incremental compilation", which has been described in a 2016 blog post. When incremental compilation is turned on, the compiler breaks the input source into pieces, and tracks how those input pieces influence the final build product. Then, when the inputs change, it detects this and reuses artifacts from previous builds, striving to expend effort solely on building the parts that need to respond to the changes to the input source code.
Fingerprints are part of our architecture for detecting when inputs change. More specifically, a fingerprint (along with some other state to establish context) is a 128-bit value intended to uniquely identify internal values used within the compiler. Some compiler-internal results are stored on disk ("cached") between runs. Fingerprints are used to validate that a newly computed result is unchanged from the cached result. (More details about this are available in the relevant chapter of the rustc dev guide.)
The fingerprint stability check is a safeguard asserting internal consistency of the fingerprints. Sometimes the compiler is forced to rerun a query, and expects that the output is the same as from a prior incremental compilation session. The newly enabled verification checks that the value is indeed as expected, rather than assuming so. In some cases, due to bugs in the compiler's implementation, this was not actually the case.
We initially added these fingerprint checks as a tool to use when
developing rustc itself, back in 2017. It was solely provided via an unstable-Z
flag, only available to nightly and development builds.
More recently, in March, we encountered a miscompilation that led us to turn on verify-ich
by default. The Rust compiler team decided it was better to catch fingerprint problems and abort compilation, rather than allow for potential miscompilations (and subsequent misbehavior) to sneak into Rust programmer's binaries.
When we first turned on the fingerprint checks by default, there was a steady stream of issues filed by users of the nightly (and beta) toolchains, and steady progress has been made on identifying fixes, a number of which have already landed.
In the past week, we had started making plans to improve the user-experience, so that the diagnostic issued by the check would do a better job of telling the programmer what to do in response. Unfortunately, this was done under the assumption that the new verification would ship in 1.53, not 1.52.
It turns out verify-ich
was turned on in version 1.52.0, which was released recently.
Today's new release, 1.52.1, works around the breakage caused by the newly added verification by temporarily changing the defaults in the Rust compiler to disable incremental unless the user knowingly opts in.
Essentially, for some crates, certain sequences of edit-compile cycles will cause rustc
to hit the "unstable fingerprints" ICE. I showed one example at the start of this blog post.
Another recent example looks like this:
thread 'rustc' panicked at 'found unstable fingerprints for predicates_of(<massive text describing rustc internals elided>)', /rustc/.../compiler/rustc_query_system/src/query/plumbing.rs:593:5
They all arise from inconsistencies when comparing the incremental-compilation cache stored on disk against the values computed during a current rustc
invocation, which means they all arise from using incremental compilation.
There are several ways that you may have incremental compilation turned on:
dev
or test
profiles which default to having incremental compilation enabled.CARGO_INCREMENTAL=1
build.incremental
setting in your Cargo configincremental
setting in your Cargo.toml for a given profileIf your project has not adjusted the defaults, then when running cargo build --release
or otherwise in the release
profile configuration incremental is
disabled on all Rust versions1, and these issues should not affect your release
builds.
The Internal Compiler Error asks you to report a bug, and if you can do so, we still want that information. We want to know about the cases that are failing.
But regardless of whether or not you file a bug, the problem can be worked around on your end by either:
cargo clean
), orCARGO_INCREMENTAL=0
in your environment or build.incremental
to false
in the config.toml
.We recommend that users of 1.52.0 upgrade to 1.52.1, which disables incremental compilation.
We do not recommend that users of 1.52.0 downgrade to an earlier version of Rust in response to this problem. As noted above, there is at least one instance of a silent miscompilation caused by incremental compilation that was not caught until we added the fingerprint checking.
If a user is willing to deal with the incremental verification ICE's, and wishes
to opt back into the 1.52.0 behavior, they may set RUSTC_FORCE_INCREMENTAL
to1
in their environment. The Rust compiler will then respect the-Cincremental
option passed by Cargo, and things will work as before, though
with the added verification. Note that this flag does not enable incremental if
it has not already been separately enabled (whether by Cargo or otherwise).
If you are currently using a toolchain prior to 1.52.0, and wish to continue doing so, we recommend that you disable incremental compilation to avoid hitting silent miscompilations.
On all Rust builds since incremental has landed, it has been a major improvement to compile times for many users, and has only improved over time. We acknowledge that the workarounds presented here and recommendations are painful, and will be working hard to ensure the situation is as temporary as possible.
We have issued 1.52.1 today which:
RUSTC_FORCE_INCREMENTAL=1
).This is intended to be a mitigation that helps the majority of Rust users have an upgrade path to a safe Rust compiler which does not have the risk of miscompiling their code, but also provide the option for users willing to deal with the errors to do so.
We expect to continue to actively invest in fixing the bugs, and depending on our confidence in the fixes, may issue a 1.52.2 point release which backports those fixes to the stable channel. Users wishing to help us test can use the nightly channel, and report bugs to rust-lang/rust with any ICEs they are seeing.
We are also currently not planning to disable incremental on the beta channel, but this decision has not been firmly committed to. A number of fixes are available on 1.53 beta today, so users who wish to continue using incremental may want to switch to that. Nightly will always have the latest in fixes, of course.
The long-term plan is to fix the bugs! Incremental compilation is the only realistic way for the Rust compiler to be able to provide a fast edit-compile-run cycle for all of its programmers, and so we need to address all of the issues that have been identified thus far via verify-ich
. (There are 32 such issues as of this writing, though many are duplicates.)
We are actively investing in this, and a number of bugs have already been identified and fixed. Depending on the state of the fixes, future stable releases (1.53 and onwards) will likely re-enable incremental compilation.
The Rust teams will also be developing plans to ensure we have better tracking systems in place in the future for bugs, both to prevent situations like this from arising again, but also to further increase the stability of our releases by tracking bugs more accurately as they propagate across channels.
The Rust team is happy to announce a new version of Rust, 1.52.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.
If you have a previous version of Rust installed via rustup, getting Rust 1.52.0 is as easy as:
rustup update stable
If you don't have it already, you can get rustup
from the appropriate page on our website, and check out thedetailed release notes for 1.52.0 on GitHub.
The most significant change in this release is not to the language or standard libraries, but rather an enhancement to tooling support for Clippy.
Previously, running cargo check
followed by cargo clippy
wouldn't actually
run Clippy: the build caching in Cargo didn't differentiate between the two. In
1.52, however, this has been fixed, which means that users will get the expected
behavior independent of the order in which they run the two commands.
The following methods were stabilized.
Arguments::as_str
char::MAX
char::REPLACEMENT_CHARACTER
char::UNICODE_VERSION
char::decode_utf16
char::from_digit
char::from_u32_unchecked
char::from_u32
slice::partition_point
str::rsplit_once
str::split_once
The following previously stable APIs are now const
.
char::len_utf8
char::len_utf16
char::to_ascii_uppercase
char::to_ascii_lowercase
char::eq_ignore_ascii_case
u8::to_ascii_uppercase
u8::to_ascii_lowercase
u8::eq_ignore_ascii_case
There are other changes in the Rust 1.52.0 release: check out what changed in Rust, Cargo, and Clippy.
Many people came together to create Rust 1.52.0. We couldn't have done it without all of you. Thanks!
The rustup working group is happy to announce the release of rustup version 1.24.1. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.
If you have a previous version of rustup installed, getting rustup 1.24.1 is as easy as closing your IDE and running:
rustup self update
Rustup will also automatically update itself at the end of a normal toolchain update:
rustup update
If you don't have it already, you can get rustup from the appropriate page on our website.
Firstly, if you have not read the previous announcement then in brief, 1.24
introduces better support for low memory systems, installs itself into the Add/Remove programs
list on Windows, and now supports using rust-toolchain.toml
files.
Shortly after publishing the 1.24.0 release of Rustup, we got reports of a regressionpreventing users from running rustfmt
and cargo fmt
after upgrading to
Rustup 1.24.0. To limit the damage we reverted the release to version
1.23.1. The only substantive change between 1.24.0 and 1.24.1 is to correct this regression.
You can check out all the changes to Rustup for 1.24.0 and 1.24.1 in the changelog!
Rustup's documentation is also available in the rustup book.
Thanks again to all the contributors who made rustup 1.24.0 and 1.24.1 possible!
Shortly after publishing the release we got reports of a regressionpreventing users from running
rustfmt
andcargo fmt
after upgrading to Rustup 1.24.0. To limit the damage we reverted the release to version 1.23.1.If you have been affected by this issue you can revert to version 1.23.1 by running the following command:
rustup self update
The rustup working group is happy to announce the release of rustup version 1.24.0. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.
If you have a previous version of rustup installed, getting rustup 1.24.0 is as easy as closing your IDE and running:
rustup self update
Rustup will also automatically update itself at the end of a normal toolchain update:
rustup update
If you don't have it already, you can get rustup from the appropriate page on our website.
rust-toolchain.toml
as a filename for specifying toolchains.Last year we released a new toml
format for the rust-toolchain
file. In order to bring Rustup closer into line with Cargo's behaviour around .cargo/config
we now support the .toml
extension for that file. If you call the toolchain file rust-toolchain.toml
then you must use the toml
format, rather than the legacy one-line format.
If both rust-toolchain
and rust-toolchain.toml
are present, then the former will win out over the latter to ensure compatibility between Rustup versions.
Rustup's component unpacker has been changed to have a smaller memory footprint when unpacking large components. This should permit users of memory-constrained systems such as some Raspberry Pi systems to install newer Rust toolchains which contain particularly large files.
Fresh installations of Rustup on Windows will now install themselves into the program list so that you can trigger the uninstallation of Rustup via the Add/Remove programs dialogs similar to any other Windows program.
This will only take effect on installation, so you will need to rerun rustup-init.exe
if you want this on your PC.
There are more changes in rustup 1.24.0: check them out in the changelog!
Rustup's documentation is also available in the rustup book.
Thanks to all the contributors who made rustup 1.24.0 possible!
On March 18th, we announced the start of the Async Vision Doc process. Since then, we've landed 24 "status quo" stories and we have 4 more stories in open PRs; Ryan Levick and I have also hosted more than ten collaborative writing sessions over the course of the last few weeks, and we have more scheduled for this week.
Now that we have a good base of "status quo" stories, we are starting to imagine what the ✨ "shiny future" ✨ might look like. We want your help! If you have a great idea for Async Rust1, then take a look at the template and open a PR! Alternatively, if you have an idea for a story but would like to discuss it before writing, you can open a "shiny future" issue. Also, we would still love to get more "status quo" stories, so please continue to share those.
When writing "shiny future" stories, the goal is to focus on the experience of Rust's users first and foremost, and not so much on the specific technical details. In fact, you don't even have to know exactly how the experience will be achieved. We have a few years to figure that out, after all. 🚀
Every "shiny future" story is a "retelling" of one or more "status quo" stories. The idea is to replay the same scenario but hopefully with a happier ending, as a result of the improvements we've made. If you don't see a "status quo" story that is right for telling your "shiny future" story, though, that's no problem! Write up your story and we'll figure out the "status quo" story it addresses. There is always the option of writing a new "status quo" story, too; we are still requesting "status quo" and "shiny future" stories, and we will do so right up until the end.
If you'd like to see what a "shiny future" story looks like, we have merged one example, Barbara Makes a Wish. This story describes Barbara's experiences using a nifty new tool that gives her lots of information about the state of her async executor. It is a "retelling" of the "status quo" story Barbara Wants Async Insights.
Here is the idea in a nutshell:
We are launching a collaborative effort to build a shared vision document for Async Rust. Our goal is to engage the entire community in a collective act of the imagination: how can we make the end-to-end experience of using Async I/O not only a pragmatic choice, but a joyful one?
As described in the original announcement, the vision document is structured as a series of "status quo" and "shiny future" stories. Each story describes the experiences of one or more of our four characters as they go about achieving their goals using Async Rust.
The "status quo" stories describe the experiences that users have today. They are an amalgamation of the real experiences of people using Async Rust, as reported to us by interviews, blog posts, and tweets. The goal with these stories is to help us understand and gauge the cumulative impact that problems can have on our users.
The "shiny future" stories describe those some characters achieving those same goals, but looking forward a few years into the future. They are meant to illustrate the experience we are aiming towards, and to give the overall context for the RFCs and other kinds of changes we want to pursue.
We are currently in the midst of the brainstorming period. This means that we are seeking to collect as many stories -- both about the "status quo" and the "shiny future" -- as we can. The brainstorming period lasts until the end of April. After that, the working group leads are going to merge the remaining stories and get to work drafting a synthesized vision document that incorporates elements of the various stories that have been submitted.
Going forward, we plan to revisit the vision document regularly. We fully expect that some aspects of the "shiny future" stories we write are going to be wrong, sometimes very wrong. We will be regularly returning to the vision document to check how things are going and adjust our trajectory appropriately.
If you'd like to help, we'd love to have you! If you've got an idea for a story, then feel free to create a PR to the wg-async-foundations repository based on one of the following templates:
If you'd like a bit more inspiration, then you can join Ryan Levick and I at one of our vision doc writing sessions. We have more sessions scheduled this week and you can look for announcements from us on twitter or check the #wg-async-foundations
stream on the rust-lang Zulip.