Rust release milestone predictions


#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!


#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.


#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.


#21

Depending on person’s background there is a long list of RFC that need the documentation status evaluated. I am happy to merge changes from forks of the gist.


#22

I’ve recently made the following changes: