Cargo script edition policy (lang/edition aspects)

[traviscross]

In the @rust-lang/cargo team RFC for cargo script (RFC 3502), the document stated a policy that when the edition is not specified in the frontmatter, cargo script will use the latest edition, whatever that is, while linting about this. Cargo script is now up for stabilization (rust-lang/cargo#16569).

As part of this, people are raising concerns about this lint and this behavior (see rust-lang/cargo#16598).

In some sense, the only fixed decisions at the time of stabilization are 1) that cargo script will work without an edition set and 2) that it will use Rust 2024 by default. We could always later decide to never change the default from Rust 2024. Due to that, if we're all happy with these two decisions (I am), I think it's OK for the stabilization to proceed. No need to block that.

But I do want to mention, as a policy matter for what happens in the next edition, that I think the @rust-lang/lang and @rust-lang/edition teams are stakeholders in this.

From an edition side, Cargo changing a default over an edition represents an edition change; I'd expect this to be an edition item.

From a lang side, for my part, I believe the language that we choose to put in front of people "using Rust™" is a lang team matter, and I think that people using cargo script will feel that they're "using Rust™". If we update the edition of Rust automatically when someone updates the toolchain, then this would make our story that editions only cause breakage in an opt-in way less true (some might say untrue). Further, breakage in scripts will not be caught by crater and so will be difficult to predict confidently.

I'd be concerned that these factors would eventually constrain our ability to use editions in the intended way to evolve the language.

As mentioned, I don't believe this needs to block the cargo script stabilization as the edition policy can be worked out later, but I do want to raise the matter for awareness in case anyone feels something about this policy matter might affect anything about the stabilization.

Related

• Tracking Issue for cargo-script RFC 3424 cargo#12207
• Stabilize cargo script cargo#16569
• RFC: cargo-script rfcs#3502
• Remove edition warning in cargo script w/o frontmatter cargo#16598

[epage]

As mentioned, I don't believe this needs to block the cargo script stabilization as the edition policy can be worked out later, but I do want to raise the matter for awareness in case anyone feels something about this policy matter might affect anything about the stabilization.

If there is a revisiting of the "use latest edition" policy, it is fundamentally a blocking issue for Cargo script stabilization. That was what we sought input from the project and community on in the RFC and is fundamental to the decision made. This is not a decision that you can pull one piece out and keep.

[nixpulvis]

From a lang side, for my part, I believe the language that we choose to put in front of people "using Rust™" is a lang team matter, and I think that people using cargo script will feel that they're "using Rust™". If we update the edition of Rust automatically when someone updates the toolchain, then this would make our story that editions only cause breakage in an opt-in way less true (some might say untrue). Further, breakage in scripts will not be caught by crater and so will be difficult to predict confidently.

This seems to be making an argument against defaulting to the latest edition of Rust from a cargo script without an edition in the frontmatter, with or without the warning.

My issue with that is that I often use cargo script to showcase and test out features of rust quickly, in addition to use as more production oriented workflow scripts. When I create a script quickly though, I would like to both use the latest version and avoid additional boilerplate of the frontmatter when I don't need it. The whole point of cargo script is reduction of boilerplate. Defaulting to 2015 would be more consistent with cargo's behavior, but somewhat unfortunate in my opinion.

It's my opinion, if you don't specify the edition, you shouldn't expect stability across edition changes in your toolchain. But I accept that could be different from stated goals of the project or other people's opinions.

[joshtriplett]

As mentioned, I don't believe this needs to block the cargo script stabilization as the edition policy can be worked out later, but I do want to raise the matter for awareness in case anyone feels something about this policy matter might affect anything about the stabilization.

If there is a revisiting of the "use latest edition" policy, it is fundamentally a blocking issue for Cargo script stabilization. That was what we sought input from the project and community on in the RFC and is fundamental to the decision made. This is not a decision that you can pull one piece out and keep.

Seconded. There was already an opportunity to advise on this, and the lint was added as an appropriate amelioration.