From c129c8be5423c532959d3eacd453ab5f475baaa8 Mon Sep 17 00:00:00 2001 From: Jakub Bukaj Date: Tue, 11 Nov 2014 17:52:32 +0100 Subject: [PATCH] Add "Futureproof `box` and `&` patterns" --- text/0000-futureproof-box-ref-patterns.md | 106 ++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 text/0000-futureproof-box-ref-patterns.md diff --git a/text/0000-futureproof-box-ref-patterns.md b/text/0000-futureproof-box-ref-patterns.md new file mode 100644 index 00000000000..ac67f793965 --- /dev/null +++ b/text/0000-futureproof-box-ref-patterns.md @@ -0,0 +1,106 @@ +- Start Date: 2014-11-11 +- RFC PR #: (leave this empty) +- Rust Issue #: (leave this empty) + +# Summary + +Futureproof `box` patterns by renaming them to `deref`. + +In an effort to consolidate `box` and `&` patterns, change the latter to use the `deref` syntax as well, in recognition of them being semantically equivalent to `box` patterns. + +Make the newly introduced `deref` keyword a non-strict keyword. + +# Motivation + +The main motivation for this RFC is to futureproof `box` patterns, which currently only work with the `Box` type. Post the 1.0 release it is likely that the Rust community decides to extend `box` patterns to support any type that implements the `Deref` family of traits to make pattern matching accessible to other user-defined types such as `Rc`. However, whilst there is an overlap between types that are `box` allocated and types that implement the `Deref` family of traits, conceptually they're distinct categories. Therefore, the `box` keyword does not seem to well reflect the meaning of the pattern and in recognition of this the RFC proposes to rename it to `deref`. + +In addition, the RFC recognises that `box` and `&` patterns are functionally identical and proposes to rename the latter to `deref` as well. + +# Detailed design + +1. Rename the `box` keyword appearing in patterns to `deref`. + + The following code: + ```rust + match ty::get(function_type).sty { + ty::ty_closure(box ty::ClosureTy { + store: ty::RegionTraitStore(..), + .. + }) => { + // ... + } + _ => { + // ... + } + } + ``` + + would, after this change, read: + ```rust + match ty::get(function_type).sty { + ty::ty_closure(deref ty::ClosureTy { + store: ty::RegionTraitStore(..), + .. + }) => { + // ... + } + _ => { + // ... + } + } + ``` + + It is proposed that the `deref` keyword be made a non-strict keyword so that user code can continue to use `deref` as the name of an identifier or an item. + +2. Change the `&` patterns to use the `deref` syntax as well. + + The following code: + ```rust + match node { + &PatWild(_) => { + // ... + } + &PatEnum(_, ref args) => { + // ... + } + _ => { + // ... + } + ``` + + would, after this change, read: + ```rust + match node { + deref PatWild(_) => { + // ... + } + deref PatEnum(_, ref args) => { + // ... + } + _ => { + // ... + } + ``` + +It is important to note that extending the proposed `deref` patterns to support types implementing the `Deref` family of traits is outside of this RFC's scope and can be proposed and introduced backwards-compatibly in the future. + +An important implication of this change is that it renders `ref` and `deref` patterns *symmetrical* in their functional meaning. + +Specifically, a pattern of the form `deref [pat]` denotes that the pattern will successfully match a value if dereferencing said value arrives at a value that matches the pattern [pat]. + +Similarly, a pattern of the form `ref [pat]` denotes that the pattern will successfully match a value if taking the address of the value will produce a value that matches the pattern [pat]. In this particular case, [pat] is restricted to always be an identifier pattern and indeed a `ref` pattern binds said identifier to a reference of the destructured value. + +# Drawbacks + +* Renaming `&` to `deref` is undoubtedly an ergonomic regression. +* Renaming `&` to `deref` will impact a substantial number of Rust code currently in existence. + +# Alternatives + +1. Restrict the RFC to only propose the first change, namely renaming `box` patterns to `deref` patterns whilst leaving `&` patterns intact. While this is still an improvement and addresses the main issue in question, it leaves the language with two constructs that are semantically equivalent. + +2. Change `box` patterns to use the `&` syntax instead. This has been considered before drafting this RFC, however, it is believed that allowing `&` in patterns destructuring non-reference types that implement one of the `Deref` traits could be a major point of confusion in the learning process. + +# Unresolved questions + +None.