Tracking issue for box_patterns feature

Box patterns were gated by RFC 469.

Will it be possible to use box patterns with smart pointers?

Odd question: I've seen a few fn method(self: Box<Self>) type things in libstd; is there any plan to eventually turn this into fn method(box self) ?

Types will be written Box<Foo> and not box Foo even if box_patterns is stabilized. Allowing box Foo would be a new feature that is not planned I think. box is useful to box values (shorter then Box::new(value) and allows some pattern matching impossible before.

Oh, I understand that in general, box Foo won't be a type. I was just wondering because I was under the assumption that &self in method definitions was more of a pattern than a type description, which means that box self in methods makes sense.

&self in methods does not work like a pattern. For example in fn foo(x: &u32) { let &y = x } the &y pattern "removes" one pointer indirection and make y have type u32, whereas in a impl SomTrait for u32 { fn bar(&self) { … }} method self has type &u32 with the &_ indirection included.

Are 'Box patterns' enabled, without flags, on Nightly yet?

@jadbox

@jadbox No. Unless someone missed something, this issue would be closed if they were.

rustc 1.18.0-nightly (2b4c911 2017-04-25)

error: box pattern syntax is experimental (see issue #29641)
 --> a.rs:2:9
  |
2 |     let box a = Box::new(1);
  |         ^^^^^
  |
  = help: add #![feature(box_patterns)] to the crate attributes to enable

error: aborting due to previous error

@SimonSapin

thanks @SimonSapin

What's left to do on the feature before it can be considered 'stable' enough for nightly?

What's left to do on the feature before it can be considered 'stable' enough for nightly?

This is related to box syntax more generally, so the questions around that need to be resolved first.

This is really critical to matching recursive enums. I have some code like:

match act {
    Subcondition(box Always(act)) => simplify(act),
    Subcondition(box cond) => Subcondition(Box::new(simplify(cond))),
    otherwise => otherwise
}

And basically, I'm stuck on nightly.

Is this box pattern syntax really super tied to the placement syntax in the other issues that are also using the box keyword? The resemblance seems cosmetic (also, the tracking issue linked here doesn't mention the pattern syntax except in passing). Boxing recursive enums is a basic thing to do, and being able to deeply match those recursive enums seems like a pure win, regardless of how placement works.

Maybe changing the keyword from box would help get this feature going again?

As discussed on the RFC for default binding modes in match (tracking issue #42640), I think the best solution here would not be box patterns, but simply to have the ref "default binding mode" automatically propagate through all types with Deref implementations (not just through & itself), and likewise the ref mut mode through all DerefMut types (and not just &mut).

So you could do things like:

let foo = Rc::new(Some(true)); // or Box, or Arc, or ...
match &foo {
    Some(b) => { /* b is of type `&bool` here */ }
    None => { ... }
}

There may or may not be complications around things like DerefPure here, I can't remember. (If the complications don't implicate safety then I think we should just accept them with, "don't write surprising Deref implementations or you'll get surprising results".)

Would it also be possible for & in patterns to go through Deref, to preserve the ability to write the "default binding mode" stuff explicitly? Or would it be better to keep box as the explicit version, and let it be stabilized on its own?

Marking Box patterns (in the literal sense of the box keyword) as perma-unstable. If there's forward progress here, it'd be under the auspices of "deref patterns".

@deontologician

@deontologician, @jonhoo, @jcotton42, @ice1000, @Robbepop, @nirvdrum, @bbqsrc and everybody else interested!

I made proc macro library, which implements deref patterns right now, in stable Rust! 🎉

https://crates.io/crates/match_deref

It will work for any type, which implements Deref, for example Box, Rc and String.

My library is not drop-in replacement for box patterns, because I call Deref::deref internally, and Deref::deref takes a reference and returns a reference. I. e. with my lib you can do this: match &Box::new(...) { Deref @ _ => ... }, but you cannot do this: match Box::new(...) { Deref @ _ => ... }. I. e. moving a value out of a box is not supported.

Also currently there is no support for DerefMut and RefCell, but they can be trivially added. It is possible that I will add support for them (check periodically my lib on crates.io ). But you can simply download the code and just edit it in few places to get DerefMut and RefCell support

maybe create new gate min_box_pattern and think about only Box on there? Is there blocker to stabilize?

@KisaragiEffective

@KisaragiEffective , there is already nearly-finished work for strings here:
#98914 . My opinion is this: we should create DerefPure as suggested in #98914 (comment) and then make String and Box both impls of DerefPure

Edit: unfortunately, this will not add ability to move out of Box

For anyone hunting for info - this #87121 is the tracking issue for deref patterns, which eliminate the need for box_patterns. So, box_patterns will eventually be deprecated and not stabilized.

Support will probably be added one by one for std types (String, Vec, Box, Rc, Arc) until a trait is decided upon that enables use on custom types like DerefPure (which could only be those where deref has no side effects, per zulip). It seems like it will be a while before we're able to use the result though, since the changes look pretty wide reaching - see the preliminary implementation for String #98914 that merged somewhat recently

Edit: couldn't find one anywhere, so here's a working example with the new string deref syntax:

#![feature(string_deref_patterns)]

fn main() {
    let s = String::from("this is a string");
    if let Some("this is a string") = Some(s) {
        println!("matches!");
    }
}

Rollup merge of rust-lang#156749 - cyrgani:unbox-full, r=Kivooeo,fmease

Unrolled build for #156749 in rollup 161731

Feature has been removed in favor of deref patterns, see #156749

Rollup merge of #156749 - cyrgani:unbox-full, r=Kivooeo,fmease

Navigation Menu

Repository navigation

Tracking issue for `box_patterns` feature #29641

31 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for box_patterns feature #29641

Description

Activity

pyfisch commented on Aug 5, 2016

clarfonthey commented on Apr 15, 2017

pyfisch commented on Apr 15, 2017

clarfonthey commented on Apr 15, 2017

SimonSapin commented on Apr 15, 2017

jadbox commented on Apr 26, 2017

SimonSapin commented on Apr 26, 2017

jadbox commented on Apr 26, 2017

steveklabnik commented on Apr 27, 2017

deontologician commented on Jan 25, 2018

glaebhoerl commented on Jan 25, 2018

rpjohnst commented on Jan 25, 2018

31 remaining items

joshtriplett commented on Dec 8, 2021

safinaskar commented on Aug 2, 2022

KisaragiEffective commented on Oct 4, 2022

safinaskar commented on Oct 15, 2022

tgross35 commented on Jan 22, 2023

tgross35 commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for `box_patterns` feature #29641