2021 edition?

The short answer is probably "yes" to all of that, but the only way to "be sure you're understanding things" is to read the RFC on the subject. For example, whether async is "sugar only" kinda depends on exactly what you mean by "async" and "sugar", since it does affect borrow checking and in some sense was bundled with the std::futures machinery and a generators feature that's still unstable. But in general, anything else I could say here would just be copy-pasting text from that RFC.

Feel free to start a new thread if you have additional questions after reading the RFC.

Depends on what "real spec" means. If we're talking a formal ISO specification document like C++, probably not. If we're talking an officially endorsed exhaustive and normative description of Rust semantics, then absolutely yes. The Grammar working group is yet another project tackling a piece of this spec work.

Would adding a Copy bound be a breaking change? Why?

No, it wouldn't, but it is an explicit design decision not to add Copy to iterators directly. You can see this with other iterators like std::iter::Empty and std::iter::Once, even though both of those could be Copy they aren't. This is fine for iterators because they are usually one shots, but ranges have a much broader use than just iterators. So forcing them inline makes them harder to use.

1 Like

I'm completely comfortable with this, as long as it is mathematically unambiguous. Note that UB is actually unambiguous in many cases; I know that if I do certain things, then I know without ambiguity that I'll be getting UB. I just get really annoyed when I can't decide if something is legal rust or not, and when I can't decide what something actually means.


It would cause churn, and async has used up all of Rust's churn budget for the next decade.

What about potential massive drastic refactorings after stabilisation of const generics and GATs?

Rust is currently missing some fundamental pieces needed for good design, so I think more waves of churn is inevitable if Rust is going to evolve.


Both will cause churn in the wild, but the important difference is that removal of deprecated APIs forces code changes before adopting a new edition. Use of cool new features is voluntary, and doesn't have to be done before switching editions.


Are you suggesting that the new range type doesn't implement Iterator directly? That would break a lot of code, since code like (1..n).enumerate() no longer compiles. If you really need the Copy bound, you could create a struct that implements Copy and From<Range>.

@yaahc kindly wrote up some notes from the edition call:


Yes, but only on the new edition. We could have rustfix automatically add into_iter if it detects any of Iterator's methods being used on ranges. So there isn't breakage, but it will require some more work to migrate.

That's true, I just find that to be really inconvenient, especially when the whole point of Range* is convenience.

There is also the problem that RangeToInclusive has private fields, which make it less ergonomic to use than any other range type.

Admittedly, these are not really a huge deal, I just thought they would make the range sugar much easier to use. (As I said in the op, I don't know if this is worth the cost)


OK, so did we decide to go for a 2021 edition or not? I feel like we all just stopped talking, but never came to any conclusions on this.

There wasn't a decision made in this thread. The core team is still discussing it, even if this thread died out.

1 Like

OK, as long it wasn't just forgotten about... thank you for letting me know!

The language team has at least a couple of items that would benefit from an edition boundary, such as proposals for "raw reference" syntax. We're still reviewing plans for a possible 2021 edition, and we haven't made any official team recommendation for whether we want to have an edition.


I know this would be too big of a change, but I wish semicolons in Rust is optional.

In general, I think the details of specific large-scale proposals should probably go in a different thread, rather than this one. However, I think this is worth responding to briefly here because it touches on the question of "what kinds of things would we want to do in an edition?". (Speaking for myself here.)

That's not the kind of change I think we'd ever consider, at an edition boundary or otherwise. While we're willing to consider changes that would require or encourage people to update their code, we normally only do so if the benefits outweigh the costs. We place a very high cost on "everyone must update their code", but we also place a rather high cost on "everyone should update their code to be idiomatic". (And we don't also generally like to create multiple idiomatic styles and risk encouraging disparate "dialects" of Rust.)

For instance, the 2018 module system potentially required updating code, but it introduced substantial consistency improvements that help people use the language; even then, we felt much better about it when we found a design where most people wouldn't need to change their code substantially. And we started requiring dyn Trait instead of just Trait for trait objects, but only because users regularly got confused by accidentally using trait objects when they didn't mean to; even despite that, I've still seen complaints from people who wish Rust didn't steer them towards adding dyn.

Even if you think Rust shouldn't have semicolons (and you'd get substantial pushback even on that point), it'd be incredibly hard to argue that the resulting massive churn would be worthwhile. That's leaving aside the people who would not want to see such a change at all, myself included.


This is a great example.

To emphasize, even this change was in fact rejected when it was first raised, in part because it was "unquestionably a big change" like Josh is describing here. It took another year of experience -- and new language features -- before people were convinced it was worth it.

(And, while reactions aren't actually important, I think it's noteworthy that the idea went from being one of the more heavily :-1:'d things to being broadly :+1:'d. Sentiment really can change, even if it doesn't always feel like it.)


Even if the idea was consensual, it would raise a lot of concerns about how to hande it, since in Rust the semicolon does not only mark the end of an instruction but also discard the type of the expression.

Removing semicolon would probably require substantial changes to the language.

1 Like

Are function types and their type system interaction part of the items that the language team considers to be significantly painful and edition worthy? In particular it doesn't seem more churny than the transition to dyn Trait, quite the opposite on first intuition, and addresses subtle soundness issues. However there doesn't seem to be an active effort to have it changed yet so it may be a little late to start for a 2021 edition.


I'm all for refactoring function types in the 2021 edition.


What would a proposed refactoring of function types look like? I've run into issue with being unable to express JIT code lifetimes recently.