Present: Mario, Joshua (remote), Jacob, Ralf, Nadri, Lukas-code, saethlin, amanieu, bee, CAD97, Jacob Degen, Jack Wrenn (remote) Context (joshlf, jswrenn): Zerocopy :: Rust All Hands / Opsem Open questions: ptr to int transmute validity of refs (how recursive) unions (what exactly is being preserved, bag of bytes/something clever about which bytes are nonnull/initialized/have(n't) provenance) ManuallyDrop of Box after it's been dropped, also ManuallyDrop+MaybeDangling

Niko's proposal made me rethink how I conceive of effects. Allow me to riff on a mental model focused on subtractive effects like const, nopanic, noalloc, nothreads etc. Frame Effects, like lifetimes, could be inferred whole-program; we choose not to. A signature is therefore a contract: by writing const fn, I: commit (compiler-checked) to never do a runtime-only operation in my function; which allows you to use my function in const context. const impl is similar: I commit to a bound on this impl and future changes of it, which you can therefore rely on.

Context At the beginnings of rust, patterns had to correspond to the matched type reference-for-reference, with patterns like &(x, ref y). This form is what we call a "fully explicit"/"fully desugared" pattern. x/ref x/ref mut x is called the "binding mode" of a binding. RFC 2005 "Match ergonomics" allowed patterns to omit &/&mut, causing a "default" binding mode to be deduced from the type. That default can still be overriden with an explicit ref x/ref mut x. After many years of experience with RFC2005 match ergonomics, two issues have come up many times, prompting us to rethink match ergonomics: The surprising "mut resets binding mode" behavior; If SomePattern(x) gives x: &T, it's not always possible to write SomePattern(&x) to get x: T (relevant issue).

My own personal notes. Documents from the successive design meetings: 2023-12-13: https://hackmd.io/YLKslGwpQOeAyGBayO9mdw 2024-05-15: https://hackmd.io/9SstshpoTP60a8-LrxsWSA 2024-06-07: https://hackmd.io/4hJmztFnS_KWG47Zemx-lw Latest source for accepted rules: https://github.com/rust-lang/rfcs/pull/3627 Design axioms The ones that feel most crucial:

Feature Name: never_patterns Start Date: (fill me in with today's date, 2024-10-27) RFC PR: rust-lang/rfcs#0000 Rust Issue: rust-lang/rust#118155 Summary A ! pattern indicates a type with no valid values. It is used to indicate an impossible case when matching an empty type in unsafe code. enum Void {} unsafe fn empty_tup<T>(tup: *const (T, Void)) -> ! {

Summary Today's match ergonomics have a series of edge cases that make it hard to predict and understand. In this RFC I propose a reframe of match ergonomics that (I hypothesize) is a better match for intuition. This is a breaking change that requires an edition. This proposal, as well as today's stable behavior, RFC3627, and several variants, can be experimented with in a web tool I wrote, inspired by (and checked against) TC's match-ergonomics-formality tool. The tool is an interactive web app that allows setting various options, comparing concrete cases, and showing rulesets in the style of this proposal. I'd like to thank everyone who participated in the various meetings about match ergonomics, and particularly TC and Waffle, for taking the time to understand this complex domain, putting forward proposals, having brilliant insights, and working to make rust better. This proposal could not have come to exist without you. Motivation Today's match ergonomics operate based on the "in-memory type" i.e. the type of the place that a subpattern matches on. This type is different than the "user-visible type" i.e. the type that would be obtained if the current pattern was replaced with a binding.

Goal: Be able to match through a Deref or DerefMut smart pointer ergonomically. let x: Option<Rc<bool>> = ...; match x { Some(deref true) => ..., Some(deref false) => ..., None => ..., } Prior discussions include:

Pattern types are the general idea of having a type T is p (e.g. u32 is 0..10), that indicates a value of type T that matches pattern p. I want this document to gather all the constraints and possibilities we've uncovered around this idea. Design Goals (opinionated) Should not break any existing code. Pattern inference should not influence runtime behavior (like UB). The same function should not need to be monomorphised multiple times for different patterns. This could be allowed as an optimization, e.g. when inlining integer division. Small changes to the code should not suddenly require more or fewer match arms. Small changes to type inference also shouldn't do that.

I'm trying to understand them. Code and docs Comments says: False edges We don't want to have the exact structure of the decision tree be visible through borrow checking. False edges ensure that the CFG as seen by borrow checking doesn't encode this. False edges are added:

Motivation We would like: To omit match arms that are unreachable, e.g. Some(_) when matching on x: Option<!>; To be explicit about side-effects, e.g. match *x {} with x: *const ! has the side-effect of asserting validity of the data at place *x, which is not clearly indicated by the match; this proposes match *x { ! } instead; To be correct, e.g. not warn "unreachable" on an arm that is in fact reachable 😅, see here. Terminology An empty type or uninhabited type is a type that has no valid value, like !, Result<!, !>, or Result<(i32, !), !>. (For this purpose, we pretend that private fields in foreign structs are inhabited).