1.42 release post

Author: steveklabnik

posts/2020-03-12-Rust-1.42.md

@@ -0,0 +1,175 @@
+---
+layout: post
+title: "Announcing Rust 1.42.0"
+author: The Rust Release Team
+release: true
+---
+
+# Announcing Rust 1.42.0
+
+The Rust team is happy to announce a new version of Rust, 1.42.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust 1.42.0 is as easy as:
+
+```console
+rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website, and check out the [detailed release notes for 1.42.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1420-2020-03-12
+
+## What's in 1.42.0 stable
+
+The highlights of Rust 1.42.0 include: more useful panic messages when `unwrap`ping, subslice patterns, the deprecation of `Error::description`, and more. See the [detailed release notes][notes] to learn about other changes not covered by this post.
+
+### Useful line numbers in `Option` and `Result` panic messages
+
+In Rust 1.41.1, calling `unwrap()` on an `Option::None` value would produce an error message looking something like this:
+
+```
+thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /.../src/libcore/macros/mod.rs:15:40
+```
+
+Similarly, the line numbers in the panic messages generated by `unwrap_err`, `expect`, and `expect_err`, and the corresponding methods on the `Result` type, also refer to `core` internals.
+
+In Rust 1.42.0, all eight of these functions produce panic messages that provide the line number where they were invoked. The new error messages look something like this:
+
+```
+thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/main.rs:2:5
+```
+
+This means that the invalid call to `unwrap` was on line 2 of `src/main.rs`.
+
+This behavior is made possible by an annotation, `#[track_caller]`. This annotation is not yet available to use in stable Rust; if you are interested in using it in your own code, you can follow its progress by watching [this tracking issue][track-caller-tracking-issue].
+
+[track-caller-tracking-issue]: https://github.com/rust-lang/rust/issues/47809
+
+### Subslice patterns
+
+In Rust 1.26, we stabilzed "slice patterns," which let you `match` on slices. They looked like this:
+
+```rust
+fn foo(words: &[&str]) {
+    match words {
+        [] => println!("empty slice!"),
+        [one] => println!("one element: {:?}", one),
+        [one, two] => println!("two elements: {:?} {:?}", one, two),
+        _ => println!("I'm not sure how many elements!"),
+    }
+}
+```
+
+This allowed you to match on slices, but was fairly limited. You had to choose the exact sizes
+you wished to support, and had to have a catch-all arm for size you didn't want to support.
+
+In Rust 1.42, we have [expanded support for matching on parts of a slice][67712]:
+
+```rust
+fn foo(words: &[&str]) {
+    match words {
+        ["Hello", "World", "!", ..] => println!("Hello World!"),
+        ["Foo", "Bar", ..] => println!("Baz"),
+        rest => println!("{:?}", rest),
+    }
+}
+```
+
+The `..` is called a "rest pattern," because it matches the rest of the slice. The above example uses the rest pattern at the end of a slice, but you can also use it in other ways:
+
+```rust
+fn foo(words: &[&str]) {
+    match words {
+        // ignore everything but the last element, which must be "!"
+        [.., "!"] => println!("!!!"),
+        
+        // start is a slice of everything except the last element, which must be "z"
+        [start @ .., "z"] => println!("starts with: {:?}", start),
+        
+        // end is a slice of everything but the first element, which must be "a"
+        ["a", end @ ..] => println!("ends with: {:?}", end),
+
+        rest => println!("{:?}", rest),
+    }
+}
+```
+
+If you're interested in learning more, we published [a post on the Inside Rust blog](https://blog.rust-lang.org/inside-rust/2020/03/04/recent-future-pattern-matching-improvements.html) discussing these changes as well as more improvements to pattern matching that we may bring to stable in the future!
+
+
+### [`matches!`]
+
+This release of Rust stabilizes a new macro, [`matches!`](https://doc.rust-lang.org/nightly/std/macro.matches.html). This macro accepts an expression and a pattern, and returns true if the pattern matches the expression. In other words:
+
+```rust
+// with the match keyword
+match self.partial_cmp(other) {
+    Some(Less) => true,
+    _ => false,
+}
+
+// with the matches! macro
+matches!(self.partial_cmp(other), Some(Less))
+```
+
+You can also use features like `|` patterns and `if` clauses:
+
+```rust
+let foo = 'f';
+assert!(matches!(foo, 'A'..='Z' | 'a'..='z'));
+
+let bar = Some(4);
+assert!(matches!(bar, Some(x) if x > 2));
+```
+
+### `use proc_macro::TokenStream;` now works
+
+In Rust 2018, we [removed the need for `extern crate`](https://doc.rust-lang.org/stable/edition-guide/rust-2018/module-system/path-clarity.html#no-more-extern-crate). But procedural macros were a bit special, and so when you were writing a procedural macro, you still needed to say `extern crate proc_macro;`.
+
+In this release, [you no longer need this line when working with the 2018 edition; you can use `use` like any other crate][cargo/7700]. Given that most projects will already have a line similar to `use proc_macro::TokenStream;`, this change will mean that you can delete the `extern crate proc_macro;` line and your code will still work. This change is small, but brings procedural macros closer to regular code.
+
+### Libraries
+
+- [`iter::Empty<T>` now implements `Send` and `Sync` for any `T`.][68348]
+- [`Pin::{map_unchecked, map_unchecked_mut}` no longer require the return type
+   to implement `Sized`.][67935]
+- [`io::Cursor` now implements `PartialEq` and `Eq`.][67233]
+- [`Layout::new` is now `const`.][66254]
+
+### Stabilized APIs
+
+- [`CondVar::wait_while`] & [`CondVar::wait_timeout_while`]
+- [`DebugMap::key`] & [`DebugMap::value`]
+- [`ManuallyDrop::take`]
+- [`ptr::slice_from_raw_parts_mut`] & [`ptr::slice_from_raw_parts`]
+
+### Other changes
+
+[relnotes-cargo]: https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-142-2020-03-12
+[relnotes-clippy]: TODO
+
+There are other changes in the Rust 1.42.0 release: check out what changed in [Rust][notes], [Cargo][relnotes-cargo], and [Clippy][relnotes-clippy].
+
+
+### Compatibility Notes
+
+We have two notable compatibility notes this release: a deprecation in the standard library, and a demotion of 32-bit Apple targets to Tier 3.
+
+#### Error::Description is deprecated
+
+Sometimes, mistakes are made. The `Error::description` method is now considered to be one of those mistakes. The problem is with its type signature:
+
+    fn description(&self) -> &str {
+    
+Because `description` returns a `&str`, it is not nearly as useful as we wished it would be. This means that you basically need to return the contents of an `Error` verbatim; if you wanted to say, use formatting to produce a nicer description, that is impossible: you'd need to return a `String`. Instead, error types should implement the `Display`/`Debug` traits to provide the description of the error.
+
+This API has existed since Rust 1.0. We've been working towards this goal for a long time: back in Rust 1.27, we ["soft deprecated" this method](https://github.com/rust-lang/rust/pull/50163). What that meant in practice was, we gave the function a default implementation. This means that users were no longer forced to implement this method when implementing the `Error` trait. In this release, [we mark it as *actually* deprecated][66919], and took some steps to de-emphasize the method in `Error`'s documentation. Due to our stability policy, `description` will never be removed, and so this is as far as we can go.
+
+#### Downgrading 32-bit Apple targets
+
+Apple is no longer supporting 32-bit targets, and so, neither are we. They have been downgraded to Tier 3 support by the project. For more details on this, check out [this post](https://blog.rust-lang.org/2020/01/03/reducing-support-for-32-bit-apple-targets.html) from back in January, which covers everything in detail.
+
+## Contributors to 1.42.0
+
+Many people came together to create Rust 1.42.0. We couldn't have done it without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.42.0/)