Tracking issue for `box_patterns` feature

[aturon]

Box patterns were gated by RFC 469.

[pyfisch]

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

[clarfon]

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) ?

[pyfisch]

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.

[clarfon]

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.

[SimonSapin]

&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.

[jadbox]

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

[SimonSapin]

@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

[jadbox]

thanks @SimonSapin

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

[steveklabnik]

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.

[deontologician]

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?

[glaebhoerl]

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".)

[rpjohnst]

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?

[glaebhoerl]

I would prefer to deprecate & and &mut (and ref and ref mut) in pattern contexts and just do this kind of adjustment on the RHS when necessary (in expression context) - so in this case, just use * to deref as normal - which may not always be as ideal as possible from a code-golf perspective, but is generally much clearer and less of a learning hazard.

[rpjohnst]

I don't think binding modes are as expressive on their own, though. We would need something beyond the RFC in order to fully remove &/&mut, no?

Or did you mean forcing people to add * in the match arm after the pattern? I feel like that's a step backwards and we don't have a clear path to avoiding that either.

[glaebhoerl]

There was some discussion about these things on the RFC, but I don't really remember it. In either case, this is getting into the weeds; I think the part that's important for now is just that the use case that was going to be satisfied by box patterns should be satisfied by extending default binding modes instead. After that I would like to also be able to remove all the other things from patterns, if there aren't any major obstacles (e.g. strictly reduced expressivity), but we can attend to those details later in the process (e.g. I'm imagining the first thing would end up as one RFC / feature flag and the second as another, later on, or something).

[deontologician]

@glaebhoerl So the best place to discuss this is default binding modes then? Is there much momentum there?

[glaebhoerl]

@deontologician Yes I'd think so (go ahead and drop a line there if the use case is important to you). Default binding modes itself (based on the tracking issue) is implemented but has a ways to go before stabilization; there hasn't been any "official" discussion about doing the thing I described, but a few people have seemed to agree that it seems like a promising direction to move in.

[deontologician]

Yeah, looks like discussion of that part is picked up in rust-lang/rfcs#2099 which doesn't have an RFC yet. I'll move my focus there, thanks!

[jonhoo]

@pnkfelix Is there a planned path to stabilization for this? The feature gate landed in #22175 quite some time ago, and this is pretty essential for doing nested matches over struct and enums that contains boxes.

[jcotton42]

Bumping this since it's been 11 months and I'm also interested in this (don't have any specific use case, just interested)