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?

[clarfonthey]

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.

[clarfonthey]

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.