report.md

Author: Nadrieril

partial-stab-report.md

@@ -0,0 +1,144 @@
+# Partial Stabilisation Report
+
+Pattern-matching on empty types is tricky around unsafe code. For that reason, current stable rust conservatively requires arms for empty types in all but the simplest case. It has long been the intention to allow omitting empty arms when it's safe to do so. The [`exhaustive_patterns`](https://github.com/rust-lang/rust/issues/51085) feature allows the omission of all empty arms, but hasn't been stabilized because that was deemed dangerous around unsafe code.
+
+I propose we stabilize an uncontroversial subset of `exhaustive_patterns`.
+
+## Summary
+
+I propose we stabilize the following subset of `exhaustive_patterns`: when the data we're matching on is guaranteed to be valid, then we allow empty arms to be omitted. This covers cases where we match something by value. E.g.:
+
+```rust
+let x: Result<T, !> = foo();
+match x { // ok
+    Ok(y) => ...,
+}
+let Ok(y) = x; // ok
+```
+
+If the place is not guaranteed to hold valid data (namely ptr dereferences, ref dereferences (conservatively) and union field accesses), then we keep stable behavior i.e. we require arms for the empty cases.
+
+```rust
+unsafe {
+    let ptr: *const Result<u32, !> = ...;
+    match *ptr {
+        Ok(x) => { ... }
+        Err(_) => { ... } // still required
+    }
+}
+let foo: Result<u32, &!> = ...;
+match foo {
+    Ok(x) => { ... }
+    Err(&_) => { ... } // still required
+}
+```
+
+Note how we conservatively consider that a valid reference can point to invalid data, hence arms of type `&!` and similar cases cannot be omitted. In general we don't allow omitting empty arms when matching behind references. This is a trickier case that I would like to intentionally postpone to later.
+
+Note also that this only allows more code to compile (though it will also raise the "unreachable pattern" lint in more cases).
+
+### Documentation
+
+I have not yet updated relevant documentation, and will do so if the FCP is accepted.
+
+### Tests
+
+The relevant tests are in `tests/ui/pattern/usefulness/empty-types.rs`.
+
+### Unresolved Questions
+
+This intentionally sidesteps the unresolved questions of the feature by stabilizing the uncontroversial subset.
+
+
+## Comparison with stable rust
+
+This proposal only affects match checking of empty types (i.e. types with no valid values, taking visibility into account). The behavior of non-empty types is not changed. Note that everything below is phrased in terms of `match` but applies equallly to `if let` and other pattern-matching expressions.
+
+For normal types, exhaustiveness checking requires that we list all variants (or use a wildcard). For empty types it's more subtle: in some cases we require a `_` pattern even though there are no valid values that can match it. This is where the difference lies.
+
+### Stable rust
+
+Under current stable rust, a `_` is required for all empty types, except specifically: if the matched expression is of type `!` (the never type) or `EmptyEnum` (where `EmptyEnum` is an enum with no variants), then the `_` is not required.
+
+```rust
+let foo: Result<u32, !> = ...;
+match foo {
+    Ok(x) => ...,
+    Err(_) => ..., // required
+}
+let foo: Result<u32, &!> = ...;
+match foo {
+    Ok(x) => ...,
+    Err(_) => ..., // required
+}
+let foo: &! = ...;
+match foo {
+    _ => ..., // required
+}
+let foo: (u32, !) = ...; // actually impossible but for the sake of example
+match foo {
+    _ => ..., // required
+}
+unsafe {
+    let ptr: *const ! = ...;
+    match *ptr {} // allowed
+    let ptr: *const (u32, !) = ...;
+    match *ptr {
+        (x, _) => { ... } // required
+    }
+    let ptr: *const Result<u32, !> = ...;
+    match *ptr {
+        Ok(x) => { ... }
+        Err(_) => { ... } // required
+    }
+}
+```
+
+### After this is stabilized
+
+With this PR, a `_` is required to match on an empty type if (and only if) the empty type is under a dereference or a union field access, *except* if the matched expression is  `!` or `EmptyEnum` where we have a backwards-compabitility exception.
+
+In all other cases (a large number), patterns of empty types can be omitted.
+
+```rust
+let foo: Result<u32, !> = ...;
+match foo {
+    Ok(x) => ..., // `Err` not required
+}
+let foo: Result<u32, &!> = ...;
+match foo {
+    Ok(x) => ...,
+    Err(_) => ..., // required because `!` is under a dereference
+}
+let foo: &! = ...;
+match foo {
+    _ => ..., // required because `!` is under a dereference
+}
+let foo: (u32, !) = ...; // actually impossible but for the sake of example
+match foo {} // allowed
+unsafe {
+    let ptr: *const ! = ...;
+    match *ptr {} // allowed for backwards-compatibility
+    let ptr: *const (u32, !) = ...;
+    match *ptr {
+        (x, _) => { ... } // required because the matched place is under a dereference
+    }
+    let ptr: *const Result<u32, !> = ...;
+    match *ptr {
+        Ok(x) => { ... }
+        Err(_) => { ... } // required because the matched place is under a dereference
+    }
+}
+```
+
+## Alternatives
+
+I know I can't avoid the `&<empty>` discussion. A possible solution for that case would be: allow omitting empty patterns behind references. The cases most relevant to `unsafe` are unions and pointers anyway, and we won't allow omitting arms in those cases. Moreover having a `&<empty>`, while not technically UB, is more unsafe than having a partially-initialized pointer or union as it's easier to dereference accidentally.
+
+Note that it's not just `&!` (which [could be decided to be uninhabited](https://github.com/rust-lang/unsafe-code-guidelines/issues/413)) but also `&(u32, !)`, which is possibly less likely to be decided to be uninhabited.
+
+## Future possibilities
+
+It is likely that we will never allow omitting empty arms behing pointer dereferences and union field accesses. The alternative for that is [*never patterns*](https://github.com/rust-lang/rust/issues/118155), which are being worked on separately.
+
+The case of references is unsettled, and depends on decisions such as [whether `&!` is uninhabited](https://github.com/rust-lang/unsafe-code-guidelines/issues/413). This is purposefully excluded from the present stabilization.