Rust release milestone predictions

1

This post is a wiki. Anybody can edit it! Make your best guesses.

Hey there. I just finished some unstable feature triage. It seems like there’s a lot cooking. Lately I’ve been anxious about filling the feature pipeline, and making sure we have big-ticket things to crow about in release announcements, so I’ve projected forward a few releases the things that seem like they are in the works.

So here’s all the stuff on my radar right now, with wild guesses as to when they will arrive. Are there any other high-impact features in the works that seem on-target to land in the next 6 months or so?

Any counter-opinions about where these will land?

I hope that having these layed out will make it clearer what to prioritize, to recognize what needs to happen to get a feature on the trains before its beta branches.

1.23 - January 04 (2018), branches November 21

  • ???

1.24 - February 15 (2018), branches January 02

  • ???

Horizon

These are features actively being worked on, that have some sort of pressure to stabilize, or that are otherwise something to emphasize during releases.

Past milestones

1.22 - November 23, branches October 12

1.21 - October 12, branches August 31

1.20 - August 31, branches July 20

1.19 - July 20, branches June 8

Milestone. Relnotes.

1.18 - June 8, branches April 27

Release notes. Milestone.

1.17 - April 27, branches March 16

1.16 - March 16, branches Feb 2

Release notes. Milestone.

1.15 - Feb 2

Release notes.

  • Macros 1.1
  • Empty tuple structs
  • Name resolution cleanup
  • Improved sorting algo
  • rustbuild
  • tokio 0.1 - we probably can’t talk about this in release announcement unless we rationalize a format for highlighting community projects
26 Likes
2

I’ve added macro use and reexport to 1.17. This allows use and pub use to work with macros. @jseyfried has been quietly making this possible for months.

2 Likes
3

Is it particularly enabled by this release? If so, that's how I would present it.

4

I turned the OP into a wiki, which means others should be able to edit.

5

I’ve updated the projections. FYI custom CRT linkage, numeric field names, and field init shorthand all slipped from my 1.16 guesses (admittedly) to 1.17. Anybody have any new estimates for when interesting stuff will land?

6

Is someone able to show me the point of Numeric field names? They don't look nice.

7

I agree it doesn't look particularly nice, but since it's more of a consistency fix than a real feature it makes sense to me.

It's explained in the RFC as follows:

New: Permit using tuple structs and tuple variants in braced struct patterns and expressions requiring naming their fields - TS{0: expr}/TS{0: pat}/etc. While this change is important for consistency, there's not much motivation for it in hand-written code besides shortening patterns like ItemFn(_, _, unsafety, _, _, _) into something like ItemFn{2: unsafety, ..} and ability to match/construct tuple structs using their type aliases. However, automatic code generators (e.g. syntax extensions) can get more benefits from the ability to generate uniform code for all structure kinds. #[derive] for example, currently has separate code paths for generating expressions and patterns for braces structs (ExprStruct/PatKind::Struct), tuple structs (ExprCall/PatKind::TupleStruct) and unit structs (ExprPath/PatKind::Path). With proposed changes #[derive] could simplify its logic and always generate braced forms for expressions and patterns.

8

@petrochenkov Can you possibly produce a vivid example of the differences in typo suggestions between 1.15 and 1.16?

9

@brson There’s an UI test (https://github.com/rust-lang/rust/blob/master/src/test/ui/resolve/levenshtein.rs / https://github.com/rust-lang/rust/blob/master/src/test/ui/resolve/levenshtein.stderr) giving several typo examples that get no suggestions in 1.15 and get suggestions in 1.16

10

In 1.17? You're… optimistic! :joy:

11

Ha ha. OK, I bumped it to 1.18. Feel free to edit it the predictions yourself!

1 Like
12

It might be possible to talk about the improved reference before it’s completely up to date. Like, “in this release the reference is not known to be incorrect”.

13

Ah, nice! I’ll edit if we make good progress on it. I’m hopeful I’ll finish the tracking issue this weekend and then we can spawn off all the tracking issues. At a minimum we’ll be able to say that we added documentation for RFCs on any given release, which will be great.

My personal goal was just to have this done in 2017! :joy: If we get good community contributions, though, we might get there in the next few months. Stretch goal: the 2-year-birthday.

1 Like
14

I believe its to make it easier to handle tuples vs structs in macros.

15

I’d like to see unions https://github.com/rust-lang/rust/issues/32836 in the horizon. It seems especially important for determining the size of ffi foreign objects with unions in them from the rust side.

16

Thanks @crlf0710. I put it under 1.18.

17

I changed the 1.18 release date from June 1 to June 8 to be 6 weeks after the 1.17 release date. Let me know if there was a reason it was abbreviated to 5 weeks.

18

Thanks @dtolnay. Probably just bad math.

19

@chriskrycho I had no idea you were working on the reference, what sort of progress have you made? This seems like the perfect sort of thing to advertise around to get a bunch of eyes on it, but I’d rather only do that once you think it’s ready.

20

@bstrie The tracking issue is set up for contribution. It looks like there are work items there to pick off.