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.
4 Likes
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.
31 Likes
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 
'd things to being broadly 
'd. Sentiment really can change, even if it doesn't always feel like it.)
12 Likes
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.
3 Likes
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.
4 Likes
I'm all for refactoring function types in the 2021 edition.
2 Likes
What would a proposed refactoring of function types look like? I've run into issue with being unable to express JIT code lifetimes recently.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.