Stream: project leads (public)

Topic: Edition policy


nikomatsakis (Jul 10 2020 at 14:34, on Zulip):

Hey folks -- @Steve Klabnik and I were working on a draft RFC regarding Rust 2021 and future editions. The text is available in this hackmd, feel free to leave comments. The gist of it is as follows:

The plan for editions was laid out in [RFC 2052] and Rust had its first edition in 2018. This effort was in many ways a success but also resulted in some difficult lessons. As part of this year's roadmap, one of the major questions we identified was that we need to decide whether we are going to do more editions and -- if so -- how we are going to manage the process.

[RFC 2052]: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md

This RFC proposes a specific answer to those questions:

BatmanAoD (Kyle Strand) (Jul 10 2020 at 20:37, on Zulip):

Interesting. Was there any thought to extending the "train" schedule period to four (or even five) years instead of three? New features are not generally blocked on edition releases, and I haven't gotten the feeling that a hypothetical 2021 edition will be particularly notable. So I wonder if setting in stone a three-year cadence might be overly aggressive for no reason.

Lokathor (Jul 10 2020 at 21:17, on Zulip):

15 to 18 is 3, and people would hate it forever, and i mean quite literally forever, if one edition time frame was 3 and all the rest were some not-3 value.

Manish Goregaokar (Jul 10 2020 at 21:18, on Zulip):

The general idea was that EITHER:

we went with the former. it's fine if the editions aren't notable, we would actually prefer for the editions to not be super notable, 2018 ended up being a lot of work to do at once

Lokathor (Jul 10 2020 at 21:19, on Zulip):

2021 actually has at least one breaking change lined up for it so far, and even one such change is enough when part of the point is also to keep to a schedule so as to keep the process smooth.

Lokathor (Jul 10 2020 at 21:20, on Zulip):

(rather, it's proposed for 2021 but not fully ratified, etc etc)

simulacrum (Jul 10 2020 at 21:22, on Zulip):

IMO 5 years feels a bit on the long side, 3 years feels like a good cadence -- sort of exploration/development/polish type cycling

Lokathor (Jul 10 2020 at 21:31, on Zulip):

possible prior art: Haskell also lets you specify the spec you target (but no practical project follows those specs since everyone uses extensions all the time)

Josh Triplett (Jul 11 2020 at 04:52, on Zulip):

@Lokathor I've seen mention of a couple of potential changes; which one did you have in mind that's breaking?

Lokathor (Jul 11 2020 at 04:54, on Zulip):

Ah, there I was thinking of the "unsafe calls require unsafe blocks even within unsafe fn" going from allow by default to deny by default.

Josh Triplett (Jul 11 2020 at 04:55, on Zulip):

Ah, that.

Josh Triplett (Jul 11 2020 at 04:55, on Zulip):

I think we haven't completely committed to that changing in the 2021 edition; it seems likely, but we need to see how the warning does in the ecosystem first, I think.

Josh Triplett (Jul 11 2020 at 04:56, on Zulip):

And we've seen a couple of cases where it introduce a lot of unsafe fn foo() { unsafe {, so it may be important to think about those ergonomics and that phrasing.

Lokathor (Jul 11 2020 at 04:59, on Zulip):

As long as it's deny by default and never ever an unchangeable hard error it's fine

Lokathor (Jul 11 2020 at 04:59, on Zulip):

people can simply put an allow on their module

Lokathor (Jul 11 2020 at 05:01, on Zulip):

And speaking as a person who mostly writes libraries full of hundreds of unsafe functions and unsafe calls, it's a good thing for people to by default have an extra guard rail on.

XAMPPRocky (Jul 11 2020 at 06:53, on Zulip):

Reading at the draft wouldn't the "unsafe in unsafe" be an "idiom lint" and thus be warn by default in 2021 not deny by default?

nikomatsakis (Jul 16 2020 at 19:54, on Zulip):

There are several proposed "migrations"

nikomatsakis (Jul 16 2020 at 19:54, on Zulip):

the one I keep bringing up as an example is rfc#2229

nikomatsakis (Jul 16 2020 at 19:55, on Zulip):

another I just saw is a proposed change to the semantics of panic!("{var}"), so that it would mean panic!("{}", var), essentially

nikomatsakis (Jul 16 2020 at 19:55, on Zulip):

there were more, too, but I forget =) I think one of the things we also talked about was reserving space for keyword arguments, but I'd be reluctant to do that (per this RFC) without active work going on in that space

nikomatsakis (Jul 16 2020 at 19:56, on Zulip):

it's hard to know the "perfect" duration for editions though indeed the hope is that they will be small and regular

BatmanAoD (Kyle Strand) (Jul 16 2020 at 20:27, on Zulip):

what do you mean by "reserving space" here?

Florian Gilcher (Jul 16 2020 at 20:50, on Zulip):

nikomatsakis said:

another I just saw is a proposed change to the semantics of panic!("{var}"), so that it would mean panic!("{}", var), essentially

I'm pretty hesitant on such miniscule changes.

nikomatsakis (Jul 16 2020 at 22:23, on Zulip):

Do you mean you'd prefer not to have accepted the RFC?

Lokathor (Jul 17 2020 at 01:23, on Zulip):

(For reference, https://github.com/rust-lang/rfcs/blob/master/text/2795-format-args-implicit-identifiers.md)

Florian Gilcher (Jul 17 2020 at 13:11, on Zulip):

nikomatsakis said:

Do you mean you'd prefer not to have accepted the RFC?

Yes, but there might be some bias of "i have learned it the old way". It does introduce a situation where we have 2 versions of a concept and I'm not sure how large the group of people sees this as so important.

There might also just be some background burn of spending much time in communities that tried to kill every character and line of code in the name of brevity and ease :).

I would definitely not feel bad if it were adopted in an edition.

XAMPPRocky (Jul 17 2020 at 13:30, on Zulip):

FWIW, the current code you have to write is actually a bit bigger. To be able to write "{var}" in a format macro today you have to write panic!("{var}", var = var), and when you have to write var = var for each variable you want to interpolate in your string it becomes a bit of mess at the end of your format string.

nikomatsakis (Jul 17 2020 at 13:39, on Zulip):

I updated the RFC appendix with those two examples

nikomatsakis (Jul 17 2020 at 13:40, on Zulip):

BatmanAoD (Kyle Strand) said:

what do you mean by "reserving space" here?

I meant basically making things like foo(a=a) become an error so that at some point the syntax can be repurposed for named arguments

Lokathor (Jul 17 2020 at 13:46, on Zulip):

just make it foo(a:a) instead

nikomatsakis (Jul 17 2020 at 14:09, on Zulip):

that is also valid syntax today

nikomatsakis (Jul 17 2020 at 14:09, on Zulip):

(type ascription)

nikomatsakis (Jul 17 2020 at 14:09, on Zulip):

(unstable, though)

nikomatsakis (Jul 17 2020 at 14:10, on Zulip):

but anyway the point is that the RFC, as written, prevents us from "reserving syntactic space" without a real plan. It would instead say that we should have an accepted RFC with the syntax we want and a plan to implement it -- and then we can make it an error as a first step in the next edition.

nikomatsakis (Jul 17 2020 at 14:10, on Zulip):

This works best if editions come out "regularly"

Last update: Jun 20 2021 at 01:15UTC