We have our 2018 roadmap for the year!

[steveklabnik]

Rust's 2018 roadmap - The Rust Programming Language Blog

[newpavlov]

If I understand correctly enabling non-2015 edition by a crate currently should be considered a breaking change. (i.e. after 1.0.0 we’ll have to publish 2.0.0 if we want to use shiny new Rust 2018) Is there any plans for enabling cargo to select crate version based on the used edition value? For example if we have two dependency versions: 1.0.0 written for Rust 2015 and 1.0.1 written for Rust 2018, and we compile our crate with Rust 2015 compiler cargo should be able to select 1.0.0 over 1.0.1. I know about relevant RFCs, but in the end they got sidetracked and closed.

[SimonSapin]

No, changing editions in a library crate should not have any effect on users of that library, who can have a different edition.

[rkruppe]

However, note that using a newer epoch is like using any new feature (new syntax, new std APIs, etc.) in that it bumps the minimum required compiler version. This is arguably a breaking change (although in practice, many crate authors don’t bump the major version for that) for users of the library because, although the library API is unchanged, they need to upgrade their compiler to even compile the library. But that’s not specific to editions.

[dan_t]

No, changing editions in a library crate should not have any effect on users of that library, who can have a different edition.

So if the public API of the library has an edition dependency (e.g. a new std type) and the user of the library uses an older edition, then the result would be just a compile error?

[SimonSapin]

Ok, starting to use features that are only present in a new Rust version is arguably a breaking change. But this is already the case today, editions do not change anything there.

My point was that having edition = 2018 in a library does not force edition = 2018 onto its users. Note that the effect of this flag is limited to opting into things like new keyword. This Cargo flag is unrelated to the “marketing” aspect of an edition in the sense of a combination of language features that might affect idioms.

[newpavlov]

My point is that pushing for crates stabilization and introducing editions without the described cargo capability will end up in effectively freezing edition for stabilized crates, which contradicts desire to evolve ecosystem semi-synchronously with editions. In other words edition represents a coherent set of features and paradigms, which ideally should translate to crates codebases as well, so in Rust 2018 you’ll work mostly with 2018 edition crates. This is the main difference with the current sad situation around minimum rustc version.

[steveklabnik]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.