Ok so 2015 gets features added to it or would this instead be the 2018 edition?
If 2015 is the only one that won't be generally feature-frozen, it really should have had a different-looking name.
Edit: That blog post says "We’ll continue to add features to Rust 2018 after its release, just like we continued to add features to Rust after the Rust 1.0 release."
Is it being feature frozen or not? I'm confused.
So for example, Rust 1.31 will add the “impl_header_lifetime_elision” feature. It does not require Rust 2018, as it is backwards compatible. As such, it’s a “Rust 2015” feature, but it will work in both.
A feature like async/await requires the async keyword. New keywords are not backwards compatible. As such, it will require Rust 2018, and will not work in 2015. However, if we release “Rust 2021” in three years, it will still work in that.
Does that make sense?
And "specific to Rust 2018" is also an awkward term. From context I think that means the set of features that are part of Rust 2018 and also existed on its release day? But that meaning is not obvious.
Is there any other term that means "the Rust 2018 set of features, as it was on release day"? It seems like something that really should have a clear name.
> From context I think that means the set of features that are part of Rust 2018 and also existed on its release day?
The "also existed on its release day" is redundant; they have to be in place on release day. If they weren't, then they'd be breaking.
> The "also existed on its release day" is redundant; they have to be in place on release day. If they weren't, then they'd be breaking.
I don't know how to reconcile these two sentences.
If yes, then how do you best distinguish "Rust 2018 with additions" from "Rust 2018, the original 2018 version"?
If no, then there are some extremely misleading descriptions of what an 'edition' is, because they don't mention that 2015 is special.
You cannot, no.
> there are some extremely misleading descriptions of what an 'edition' is
Where?
I am sorry you're this confused. I don't think I know how to explain this to you.
"Beyond that, it’s also important to mention that this release will be the initial release of Rust 2018; in some sense, it’s the start, not the end. We haven’t formally committed to a schedule for editions, but it’s likely that the next one will be Rust 2021. We’ll continue to add features to Rust 2018 after its release, just like we continued to add features to Rust after the Rust 1.0 release.
"It’s also important to note that Rust 2015 is not frozen. Anything that does not require being a part of Rust 2018 will work on Rust 2015 as well. This is due to the way editions work; given the small nature of possible changes, the compiler uses the same internal representation for all editions."
That seems to directly contradict your first answer. Is there some subtlety I'm missing?
> You cannot, no.
So let's assume I think of a new syntax which is compatible with existing Rust 2018 code, but which is syntactic sugar for async code (so not compatible with Rust 2015 code). Are you saying that this can not be added until Rust 2021 comes along? Or are you saying that you can add it but it won't be Rust 2018?
If the latter is the case I think it's really confusing to call impl_header_lifetime_elision a Rust 2015 feature.
It’s really not clear to me what exactly you’re proposing, but it sounds like breaking syntax, and so yes, it would have to wait.
That sounds like Rust 2018 would get a new feature, something that sounds in contradiction with a feature freeze.
> It’s really not clear to me what exactly you’re proposing, but it sounds like breaking syntax, and so yes, it would have to wait.
I was trying to clarify things by proposing a particular situation, a non-breaking syntax change, so I'm not sure how that could possibly sound like breaking syntax.
If you believe it's impossible for syntactic sugar to be introduced with backwards compatibility then how do you explain the question mark operator for Error handling?
? isn’t sugar, and also isn’t a breaking change.
Because that's what you seem to claim when you're saying that Rust 2018 will be feature-frozen.
> ? isn’t sugar, and also isn’t a breaking change.
? is not a breaking change, but is a new feature. That's the whole point. (also it's syntactic sugar by any definition of that word that I'm familiar with, I'd be interested to hear what your definition is, but it's otherwise besides the point).
? isn’t syntax sugar because it doesn’t desugar into other syntax, it’s a feature in its own right. At least, that’s what I recall. Regardless, I don’t think it really matters.
It may be unlikely that such changes exist, but evidence from two different people has shown that it's at least something that can be considered (even if it's by people not familiar with Rust).
> At least, I can’t think of anything. Or at least, nothing that’s compatible.
Nobody asked you to come up with a che, the question was what would happen if someone did come up with such a change. The answer seems to be "it will be added" (assuming it goes through the normal process of course, I'm not claiming that a random change will be added merely because it's compatible), at that point you can no longer claim a feature freeze, because a feature freeze is a much stronger claim than merely saying "it's unlikely that there will be changes".
> We do have features for 2018 that are incompatible with 2015.
I'm fairly certain that everyone in this discussion understood that there are features in 2018 that are not in 2015, that's the whole point of having a separate edition.