Design meeting 2024-05-08: Topic

--- title: "Design meeting 2024-05-08: Deref Patterns Design Proposal(s)" tags: ["T-lang", "design-meeting", "minutes"] date: 2024-05-08 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-05-08 url: https://hackmd.io/fj68a_l1QS2xyQQFUWz0GA --- # Deref Patterns Design Proposal(s) Goal: Be able to match through a `Deref` or `DerefMut` smart pointer ergonomically. ```rust let x: Option<Rc<bool>> = ...; match x { Some(deref true) => ..., Some(deref false) => ..., None => ..., } ``` Prior discussions include: - Tracking issue https://github.com/rust-lang/rust/issues/87121 - The whole #project-deref-patterns stream on Zulip - https://hackmd.io/GBTt4ptjTh219SBhDCPO4A?view= - https://hackmd.io/vZzzEVIMRiWN_7eptYxaOg?view#deref-patterns - https://hackmd.io/rGK3QbFGSU66i1vLbNhoUg?view - Many threads on IRLO From these and my own considerations, I have come up with two related proposals. We have a working implementation (without exhaustiveness checking) of one of the proposals available under the `deref_patterns` experimental feature gate. # Proposal(s) The two proposals differ in syntax but share how they work: a `&<pat>`/`*<pat>`/`deref <pat>`/etc pattern would be allowed for stdlib smart pointers like `Box` or `Rc`, where `<pat>` would match on the pointed-to value. ```rust let x: Option<Rc<bool>> = ...; match x { Some(&true) => ..., // syntax choice 1 Some(deref true) => ..., // syntax choice 2 Some(*true) => ..., // syntax choice 2 bis Some(Rc(true)) => ..., // syntax choice 2 ter Some(true) => ..., // possible extension (implicit deref patterns) _ => ..., } ``` Everything else about patterns works the same: we can nest them, we can get immutable or mutable access, they are subject to exhaustiveness checking and the dead arm lint. Before we discuss the two syntactic options, let's start with some common design details. ## Enabled for all std smart pointers The feature would be enabled for the following std types: `Box`, `Rc`, `Arc`, `Vec`, `String`, `Cow`, `Pin`, `ManuallyDrop`, `Ref`, `RefMut`, `LazyCell`, `LazyLock`. This is sound because all those impls are sufficiently idempotent. Extending the feature to user-defined `Deref` impls is outside the scope of this proposal. ## Exhaustiveness Patterns are treated exhaustively as expected: ```rust! // This works match Box::new(true) { deref true => ..., deref false => ..., } ``` This is sound because we only enable the feature for a trusted set of types whose `Deref` impls behave well enough. #### Mixing deref and normal patterns Some `Deref` std types like `Cow` can be matched normally. For simplicity we forbid mixing deref and normal patterns. ```rust! match Cow::Owned(false) { Cow::Owned(_) => ..., deref true => ..., // ERROR: don't mix deref patterns and normal patterns _ => ..., } ``` ## Explicit vs implicit syntax The precedent with match ergonomics and the general way rust tends to work suggests that implicit deref patterns (if we want them) should desugar into an explicit form. Moreover, we need explicit syntax to disambiguate cases like: ```rust! let cowcow: Cow<Cow<bool>> = ...; match cowcow { // How do I match the inner cow? Cow::Borrowed(_) => ..., _ => ..., } ``` As such, both proposals focus on the explicit syntax. Implicit patterns are an optional extension. ## Types We follow how the rest of rust works for matches and `Deref`: we work on places. This means that `&<pat>`/`deref <pat>` operates on a place `x: P` where `P: Deref<Target=T>`, and matches `<pat>` against the place `*x` of type `T`. It does _not_ operate on a place of type `&P`/`&mut P` (except insofar as match ergonomics make it seem like it does). It also does not return a place of type `&T`/`&mut T` (again modulo match ergonomics). As we will see in Unresolved Questions, this poses an issue for string literals. Yet this is the consistent choice wrt the rest of rust.  ## The two syntax options ### Option 1: `&<pat>` ```rust match Box::new(0) { &0 => ..., // works &x => ..., // `x: u32` _ => ..., } ``` #### No match ergonomics in the explicit form Because of how `&` works today, we don't really have much choice: ```rust! match &Box::new(Some(0)) { &x => ..., // ERROR: can't move `Box` out &Some(_) => ..., // ERROR: type mismatch &&Some(0) => ..., // ok &&Some(x) => ..., // `x: u32` _ => ..., } match &mut Box::new(Some(0)) { &mut &mut Some(ref mut x)) => ..., // `x: &mut u32` _ => ..., } // Just like for `&T`, `&<pat>` eats the inherited reference if there is one. match &Some(Box::new(0)) { Some(&x) => ..., // `x: u32` Some(&0) => ..., // ok _ => ..., } // See also the discussions below about match ergonomics 2024. ``` As you can see, this proposal isn't very convenient without implicit deref patterns. #### Mutability As could be expected, `&<pat>` calls `deref` and `&mut <pat>` calls `deref_mut`. ```rust! let mut x = Box::new(Some(0)); match x { &Some(ref x) => ..., // `x: &u32` _ => ..., } match x { &mut Some(ref mut x) => ..., // `x: &mut u32` _ => ..., } match x { &Some(ref mut x) => ..., // ERROR _ => ..., } ``` Interestingly, because `&mut T: Deref`, this allows matching on `&mut T` with a `&<pat>` pattern: ```rust let mut x = 0; match Some(&mut x) { Some(&x) => ..., // `x: u32` None => ..., } ``` #### Future-compatibility with moving out/`DerefMove` Because we distinguish `&` and `&mut` the way we do, to move out we'd probably want some other syntax. Maybe `move <pat>`, maybe `*<pat>`, idk. #### Interaction with match ergonomics 2024 The [match ergonomics 2024 proposal](https://github.com/rust-lang/rust/issues/123076) includes some possible changes to `&<pat>` patterns. Depending on the exact choices made, this could conflict with deref patterns. For example: ```rust if let Some(&x) = &Some(Box::new(0)) { /// ... } ``` - Under current Rust, this is a type error. - Under deref patterns only, `x: u32`. - Under "`&<pat>` everywhere" only, `x: Box<u32>` (which gives a move error). - Under both if we take [option eat-both-layers](https://hackmd.io/YLKslGwpQOeAyGBayO9mdw?both=#Alternate-rules-for-the-behavior-of-ampltpatgt), what makes most sense is `x: u32`. - Under both if we take [option eat-one-layer](https://hackmd.io/YLKslGwpQOeAyGBayO9mdw?both=#Alternate-rules-for-the-behavior-of-ampltpatgt), what makes most sense is `x: Box<u32>`. Hence combining the features could accidentally create a breaking change. The safest choice is to disallow `&<pat>` deref patterns in the presence of match-ergonomics-inherited references, and to disallow "`&<pat>` everywhere" on `Deref` types (should be fine because `Deref` types are rarely `Copy`). That gives us freedom to land either feature in any order. We can relax restrictions once both are stable. For custom `Deref`, this may mean that implementing `Deref` on a `Copy` type can break downstream crates: ```rust // crate A #[derive(Copy, Clone)] struct Container<T>(T); impl<T> Container<T> { fn contents(&self) -> &T { &self.0 } } // crate B fn contains_true(x: &Option<Container<bool>>) -> bool { match x { // With eat-two-layers, this copies out the `Container`. // If `Container: Deref`, this would instead copy the `bool`. Some(&c) => *c.contents(), None => false, } } ``` ### Option 2: some other syntax, e.g. `deref <pat>`, `*<pat>`, or `Pointer(<pat>)` For the sake of presentation, I'll use `deref`. Any syntax different from `&` can work the same. #### Works with match ergonomics ```rust! match Box::new(0) { deref 0 => ..., deref x => ..., // `x: u32` _ => ..., } match &Box::new(0) { // The `deref` passes through references as necessary deref 0 => ..., // ok deref x => ..., // `x: &u32` _ => ..., } match &mut Box::new(0) { // The `deref` passes through references as necessary deref 0 => ..., // ok deref x => ..., // `x: &mut u32` _ => ..., } ``` This does not require implicit deref patterns to be practical. #### Mutability Mutability is inferred from the kinds of bindings we do inside the pattern. ```rust! let mut x = Box::new(Some(0)); match x { // Calls `deref()` deref Some(ref x) => ..., // `x: &u32` _ => ..., } match x { // Calls `deref_mut()` deref Some(ref mut x) => ..., // `x: &mut u32` _ => ..., } // With match ergonomics match &x { // Calls `deref()` deref Some(x) => ..., // `x: &u32` _ => ..., } match &mut x { // Calls `deref_mut()` deref Some(x) => ..., // `x: &mut u32` _ => ..., } ``` #### Future-compatibility with moving out/`DerefMove` Compatible :heavy_check_mark:. This could in fact replace the `box_patterns` feature entirely. #### Specific syntax choice Here are the proposals I've seen: - `deref <pat>`; - `*<pat>`; - `box <pat>` (already reserved keyword); - `Box(<pat>)`/`Rc(<pat>)`/`String(<pat>)`... type-specific pattern. Note that `deref <pat>` would require reserving a keyword, since `deref(x, y)` could be a tuple struct pattern and `deref ::Type` could be a path. Note that `Pointer(<pat>)` would require some rule to not conflict with tuple struct syntax. Maybe we disallow it on tuple structs, maybe some visibility-based hack. # Summary - Option 1: `&<pat>`; - drawback: likely requires the implicit form in practice which we may or may not want; - drawback: not future-compatible with something like `DerefMove`; - drawback: using a `&` pattern on something that isn't a reference could feel weird (e.g. `matches!(Rc::new(true), &true)`). - Option 2: `deref <pat>`, `*<pat>` or `Pointer(<pat>)`. - drawback: `deref` would require a keyword i.e. new edition; - drawback: `*<pat>` goes the wrong way around, e.g. `&*<pat>` looks like a reborrow but is actually two dereferences; - drawback?: `Pointer(<pat>)` doesn't fit well with the implicit syntax; - drawback: `Pointer(<pat>)` conflicts with tuple structs. Compatibility matrix: | Option | +implicit | only explicit | +move | +custom `Deref` | works in all editions | consistent with today's rust | | - | - | - | - | - | - | - | | `&<pat>` | :heavy_check_mark: | noisy | :question: | iffy with ergonomics 2024 | :heavy_check_mark: | :heavy_check_mark: | | `deref <pat>` | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :x: | sort of | | `Pointer(<pat>)` | weird | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: except tuple structs | :heavy_check_mark: | :heavy_check_mark: | | `*<pat>` | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :x: | # Unresolved questions ## The string literal issue A fun consequence of how we deal with places. ```rust! let x: String = ...; match x { // ERROR type mismatch: place has type `str`, literal has type `&str` deref "foo" => ..., _ => ..., } ``` A similar issue exists today when matching with constants of type `&T` ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9b76a0ee3f5486f569d312e50c968531)): ```rust! const FOO: &u32 = &0; match 0 { FOO => ..., // ERROR: expected `u32`, found `&u32` _ => ..., } ``` According to `@compiler-errors` this should be easy to solve for the specific case of string literals so let's ignore for now.  # Future Possibilities ## Implicit deref patterns As discussed above, we could extend match ergonomics to add implicit deref patterns as needed. #### Desugaring algorithm Today, when a concrete pattern `p` which isn't of the form `&<pat>` is used to match on a place `x: &T`, we adjust the binding mode and keep matching `p` on the place `*x`. We would extend this behavior to places `x` of type `P` where `P: Deref` is one of the supported std types. This would insert implicit deref patterns. E.g. ```rust let x: &Rc<Option<u32>> = ...; match x { Some(x) => ..., // `x: &u32` // desugars to: &&Some(ref x) => ..., // syntax choice 1 &deref Some(ref x) => ..., // syntax choice 2 _ => ..., } ``` ## User-defined `Deref` I (Nadri) am reasonably confident that we can make this *sound* (cannot cause UB) for arbitrary user-defined `Deref`s as long as we disable exhaustiveness (i.e. require a `_` arm). ```rust! struct MyBox(..); match MyBox::new(true) { deref true => ..., deref false => ..., _ => ..., // required because `MyBox` could be doing evil things. } ``` That said, there remain many design questions: - should types have to opt-in to deref patterns? - can types opt-in to exhaustiveness (with an unsafe trait)? - what are the exact requirements for soundness ([inspiration?](http://kimundi.github.io/owning-ref-rs/stable_deref_trait/trait.StableDeref.html))? - how ok is it that patterns would be running arbitrary user code? - how do we stop users from relying on details of match lowering (which we want the freedom to change in the future)? - much more; see Zulip, IRLO, and the linked documents. For that reason they're not included in the current proposal. That said, I personally think they're too cool to forbid, even if they stay perma-unstable or behind an opt-in unsafe trait. Note that this is in tension with implicit deref patterns, as this means patterns could implicitly run arbitrary user code. We could e.g. force explicit patterns when the `Deref` impl is untrusted. ## Moving out of deref patterns We could implement this today for `Box`, to match the existing deref magic (and replace box patterns). For other types, this would require a solution to the tricky `DerefMove` design issue. In either case, this requires a compatible syntax for the explicit form as discussed above. ## Mixed exhaustiveness We could allow mixing normal and deref patterns: ```rust // Considered exhaustive because the normal patterns are exhaustive by themselves. match Cow::Owned(false) { Cow::Owned(_) => ..., deref true => ..., Cow::Borrowed(_) => ..., } // Considered exhaustive because the deref patterns are exhaustive by themselves. match Cow::Owned(false) { deref true => ..., Cow::Borrowed(_) => ..., deref false => ..., } ``` (note: the hypothetical `impl Cow: DerefMut` that clones implicitly would stop `Cow` from being eligible for exhaustiveness) The two types of patterns are treated independently. In particular, exhaustiveness won't try to figure out that this is exhaustive: ```rust! match AssertUnwindSafe(true) { deref true => ..., AssertUnwindSafe(false) => ..., // ERROR: missing patterns `deref false` and `AssertUnwindSafe(true)` } ``` # Questions for the design meeting - Does the lang team want something like this? - Would anyone oppose this proposal? Are there important details missing? - Should we reserve `deref` as a keyword for 2024? - What principles can we use to decide on syntax? I think this hinges on future possibilities, i.e. implicit syntax, user-provided `Deref`, and `DerefMove`. - How do we feel about the syntax options and future possibilities? --- # Discussion ## Attendance - People: TC, tmandry, eholk, Nadri, pnkfelix, scottmcm ## Meeting roles - Minutes, driver: TC ## Mixing deref and normal pnkfelix: Text says "For simplicity we forbid mixing deref and normal patterns." *Whom* is this simpler for? pnkfelix: Is it meant to be simpler for: End users (doesn't seem likely to me)? Rustc Implementation (not sure why, as of yet)? Language documentation (most plausible I've considered)? Simplicity of the proposal itself (okay that might be most plausible of all)? Nadri: Simpler for implementation (I tried and it's annoying). Mostly I don't imagine this is very useful. Nadri: if you find a compelling use-case it's not too hard to add. pnkfelix: Main immediate motivation I am imagining is someone learning about deref-patterns may want to learn about them by investigating how adding them to existing code changes things, and forcing such people to have to change all match-arms in parallel to leverage deref-patterns sounds like an unnecessary hurdle. However, I do now see the Mixed Exhaustiveness section where you discuss mixing deref-patterns and normal-patterns. Nadri: The only type where it makes sense to mix is `Cow` fwiw, feels niche enough. Not strongly opposed. pnkfelix: This would be more compelling if arbitrary types were allowed for this. Nadri: Agreed. ## How disruptive would the `deref` keyword be? Nadri: One of the questions I'd like to figure out is whether we should reserve `deref` as a (contextual?) keyword for 2024. This hinges on: how disruptive would that be? Does it need to be a full keyword? Nadri: The cases I've been made aware are: `deref(x, y)` could be a struct pattern, and `deref ::Type` could be a path. Nadri: Does that mean we need to forbid `deref` in paths and struct names? or can we do better? TC: In Rust 2021 this could still be spelled `k#deref`. scottmcm: This would probably need to be a full keyword. Attempts to make this contextual would have to be highly restrictive. This hasn't worked out well in the past. scottmcm: Would we ever want to allow this for destructive assignment? (Collaborative example:) ```rust! fn foo() -> (Box<i32>, Box<i32>) { todo!() } let mut x: i32 = todo!(); let mut y: i32 = todo!(); (deref x, deref y) = foo(); // ??? // now x: i32 and y: i32 ``` scottmcm: Whether or not we'd ever want to do that, this supports the idea that this would probably need to be a full keyword. ```rust // This exists today. let mut x = 0; let mut y = 0; (x, y) = (1, 2); ``` --- eholk: Are there other keywords we could use? I like the keyword approach, and I think it does need to be a full keyword and `deref` is already a common method in the standard library. scottmcm: That's my instinct as well. As compared with `gen`, I could distinguish this because you don't call `deref` yourself. TC: +1. pnkfelix: I wouldn't mind, e.g. `unbox`. Nadri: We could use `box`, that's available. tmandry: I'm not sure we should reserve a keyword. We use `&` right now to unwrap a layer of indirection. And `*` is doing the opposite. So `*` would feel inconsistent. scottmcm: I'm perfectly happy with this keyword or with finding a different keyword. There is a prevalence thing here; this could be used often repeatedly in the same place, so it'd be nice if it could be short. ## Nesting pnkfelix: Just seeking confirmation: deref-patterns go through arbirary levels of `Deref` (via composition of the allow-listed types), right? I looked through the examples and didn't see an obvious example of such, but I also didn't see a counter-example showing such being rejected. Nadri: the explicit syntax goes through a single layer: ```rust let x = Box::new(Box::new(0)); let deref b = &x; // b: &Box<u32> let deref (deref b) = &x; // b: &u32 ``` The implicit syntax would go through arbitrarily many. ```rust let x = Box::new(Box::new(0)); if let 0 = &x { // works, goes through both layers } ``` pnkfelix: huh. Why? I.e. why just one layer for explicit but arbitrary for implicit? Nadri: implicit does a type-driven search, so it makes sense for it to keep digging. explicit is explicit, just like `&<pat>` doesn't go through an arbitrary number of layers. What if you do want access to the middle `Box`? ## Consistency of operators/keywords tmandry: Today we use operators/constructors for "unwrapping" and keywords for modifying a binding. I'm not a huge fan of `deref` for this reason. tmandry: Similarly, `&` already means unwrap a layer of indirection. tmandry: Right now, the keywords in patterns, `ref` and `ref mut`, modify the binding, but they don't do unwrapping. Nadri: I agree, I think `&<pat>` and `Pointer(<pat>)` are the only proposals that "go the right way". tmandry: Do people see this consistency angle. TC: I do, but on the other hand, we could see `ref` and `ref mut` as sitting on one side along an axis that extends from adding references on one side to removing them on the other. scottmcm: Question: How much do people care about the difference between Arc/Rc/Box etc.? Should we specify the kind of pointer in the pattern? eholk: I think it's common to write code that takes an `impl Deref` as an argument. The point of `deref` is that you want to be able to not care about what kind of pointer you have. tmandry: I'd agree with that general sentiment. ## Problems with `&` tmandry: The doc mentions some problems with `&` patterns but I would benefit from more detail on each of them: One, interaction with move-patterns. Nadri: `&<pat>` in this proposal means "call `deref()`". Say we want to be able to move out of boxes, how do we write that? ```rust let x: Box<T> = ...; let &y = x; // ERROR: cannot move out of &T ``` tmandry: Would `&move` make sense? ```rust let x: Box<T> = ...; let &move y = x; // ??? let _: T = y; ``` Nadri: Is that compatible with a possible `&move T` type? tmandry: Plausibly, maybe. Nadri: That would constrain that design space. We'd have to look into that interaction. tmandry: We could have a `DerefMove` trait that would work mostly as you would expect. tmandry: We could support this only the case of boxes and then extend it later. pnkfelix: This would cover this use case, but we're not saying we'd use `&move` everywhere for `deref`. tmandry: The idea here is that we'd use `&move` here and then `&` everywhere else for `deref`. --- pnkfelix: Custom `deref` is my biggest issue with `&` in patterns here. It doesn't seem like this should run user-defined code. Nadri: In expression contexts, this is already true. ```rust let x = vec![]; let _ = &x; // no deref-coercion and thus no Deref::deref call let _: &[_] = &x; // deref-coercion ==> Deref::deref call ``` --- tmandry: Two, interaction with match ergonomics 2024 and custom Deref. Nadri: The situation with match ergonomics is not really a point against `&`, it's more that there's a lot to unwind here. Nadri: Depending on the decisions we make, adding a `deref` impl on a type could become a breaking change. E.g., if we chose "eat-two-layers", then: ```rust // crate A #[derive(Copy, Clone)] struct Container<T>(T); impl<T> Container<T> { fn contents(&self) -> &T { &self.0 } } // crate B fn contains_true(x: &Option<Container<bool>>) -> bool { match x { // With eat-two-layers, this copies out the `Container`. // If `Container: Deref`, this would instead copy the `bool`. Some(&c) => *c.contents(), None => false, } } ``` tmandry: We were leaning toward "eat-one-layer". --- Nadri: Three, verbosity is a concern with the `&` syntax. In practice, I wouldn't really want to use it because you'd have to remove all match ergonomics most of the time. E.g.: ```rust let mut x = Box::new(Some(0)); match &mut x { &mut &mut Some(ref mut x)) => ..., // `x: &mut u32` _ => ..., } ``` In the above, the first `&mut` is a normal one, and the second one is doing the `deref`. With the `deref` keyword, it instead looks like this: ```rust let mut x = Box::new(Some(0)); match &mut x { deref Some(x) => ..., // `x: &mut u32` _ => ..., } ``` pnkfelix: What's the rule here for mutability with `deref`? Nadri: It works like match ergonomics. It works automatically, which seems the most convenient. TC: If I were writing the RFC, the fact that the two `&mut`s in the example above mean different things, and the confusion that would come from that, would be a key part of the motivatin. Nadri: Also I don't think ppl know enough about patterns to write what I wrote in the `&mut` case. tmandry: I wonder if we should put that much weight on consistency – if there are already `mut`s appearing in the match scrutinee or binding, it's clear mutation is happening. I can see there being issues around the distinction between a mutable reference and a mutable binding that is a reference, but we already have those issues. scottmcm: Is there a world where that first example works without the second `&mut`, or is that just implicit `deref`. Nadri: That's just implicit `deref`, but then there's no explicit form. tmandry: We should discuss more implications of implicit deref.. tmandry: I'd also like to know more about the possibilities (or not) of mixing `&` with match ergonomics. ## High level, do we want something like this? TC: Setting aside the syntax, i.e. assuming we could find something consistent and that we're happy with, does this seem to us all to be a problem worth solving (and do we understand that motivation), and so it's worth Nadri investing more effort into this? tmandry: I think the motivation is good. It's definitely something I want to see. The problem has always been what syntax do we pick. I'm glad we're looking at it with a close eye. scottmcm: +1. I'm a big fan of not having to split up matches. pnkfelix: +1. TC: +1. ## What can we rule out? TC: Are there options above that we definitely do not want? E.g. `*`? tmandry: That's my feeling, we should rule out `*`. scottmcm: I'm convinced by that. TC: +1. ## Poll TC: Let's verify the poll is accurate: Feelings poll: | Option | Nadrieril | TC | scottmcm | tmandry | pnkfelix | eholk | | - | - | - | - | - | - | - | | `&<pat>` | -0.5 | +0| | +1 | +0.5 | +0.25 | | `deref <pat>` | +0.5 | +1 | +¾ | -0.5 | +1 | +0.75 | | `box <pat>` | +0 | +0 | +¾ | -0.25 | | | | `some_keyword <pat>`| +0 | +1 | +1 | -0 | | +1 | | `<Pointer>(<pat>)` | +0.5 | -0| -0 | | +1 | -0.75 | | `Deref(<pat>)` | | +1 | +¾ | | +1 | | | `*<pat>` | -1 | -1 | -1 | -1 | | -1 | | implicit syntax (only) | -2 | -1 | | | -1 | -1 | | implicit syntax (eventually) | +0 | +0 | | +0 | | -0.5 | | custom `Deref` eventually | +1 | +1 | +1 | +1 | +1 | +1 | pnkfelix: Half (or less)-seriously, we could say `impl Deref(<pat>)`. scottmcm: As a spitball idea, we could require that you have `core::ops::Deref` in scope, and use capital `Deref`. (Discussion about custom Deref.) TC: We should think about this with respect to `derive(SmartPointer)` also, or whether a similar derive might make sense here in terms of addressing the main use cases but constraining the implementation. ## Next steps on keyword TC: For the edition, the most immediate question we need to answer is whether a new keyword need to be reserved. What next steps should we ask of Nadri so that we can figure out what we want to do here? tmandry: I think I'm `-1` on a proposal that would require anyone to write `r#deref` when implementing `Deref`. scottmcm: I'm in favor, if we're not certain, to not reserve it. If people needed to use `k#deref` for awhile, that could work. pnkfelix: Am I right that we could, in fact, use `Deref` here? scottmcm: It being a lang item doesn't affect name resolution, since it needs to be in scope to detect that it's a lang item. tmandry: If it were `impl Deref`, that would feel like the right direction. scottmcm: There is a version where `impl Deref` is the explicit form, and then with some version of match ergonomics, this is somehow mostly elided. Nadri: The implict thing doesn't work always. scottmcm: We could use rebinding of variables to work around this maybe in many cases. The key motivation here is not having to break up patterns into multiple match statements. Nadri: That works, I suppose, though it may be somewhat unergonomic. I think we can do better. All: Asks for Nadri: - Propose other keywords if a keyword is desired? - Propose a way that `deref` could work without running into tmandry's concern? - How could we do implicit in a way that doesn't make everyone sad while having an explicit form where necessary (that's maybe unwieldy)? - E.g., maybe the keyword would be `deref_pat` or something like that. - Explore whether there's some contextual keyword approach? - What things could we do to improve the `&` approach? - Would we favor the `&` option if the ergonomics could be solved, can it? - It'd be good to see representative examples written out with all of the plausible options. - Write out the set of desiderata (or design axioms) that we want out of this. - E.g. that we don't want to have to spit things up into multiple match statements just because you're using nesting. Nadri: One thing I'm getting out of this meeting is that custom `Deref` is something that we do probably want. It seems also that reserving the `deref` keyword is not urgent for Rust 2024, which is good. Nadri: I'd be happy to have a meeting a few months time after iterating on this. Nadri: Do we want to think about making this a project goal? TC: Maybe a project goal working on patterns generally could make sense (e.g. rolling in match ergonomics 2024). Then we could bring together all the desiderata in one place. There's a risk of asking too much, but there may be some good overlap also. Nadri: That's interesting. Thanks for that. scottmcm: That could indeed make sense. scottmcm: We might also want to look at the situation on projections here, e.g. with `Pin`. TC: Pointer projection also. (The meeting ended here.)