New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for `box_patterns` feature #29641

Open
aturon opened this Issue Nov 5, 2015 · 19 comments

Comments

Projects
None yet
@aturon
Member

aturon commented Nov 5, 2015

Box patterns were gated by RFC 469.

@pyfisch

This comment has been minimized.

Contributor

pyfisch commented Aug 5, 2016

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

@bstrie bstrie referenced this issue Dec 11, 2016

Closed

Tracking issue for placement new #27779

0 of 4 tasks complete

@SimonSapin SimonSapin referenced this issue Feb 19, 2017

Open

Tracking issue for 1.0.0 tracking issues #39954

9 of 28 tasks complete
@clarcharr

This comment has been minimized.

Contributor

clarcharr commented Apr 15, 2017

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

This comment has been minimized.

Contributor

pyfisch commented Apr 15, 2017

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.

@clarcharr

This comment has been minimized.

Contributor

clarcharr commented Apr 15, 2017

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

This comment has been minimized.

Contributor

SimonSapin commented Apr 15, 2017

&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

This comment has been minimized.

jadbox commented Apr 26, 2017

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

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Apr 26, 2017

@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

This comment has been minimized.

jadbox commented Apr 26, 2017

thanks @SimonSapin

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

@steveklabnik

This comment has been minimized.

Member

steveklabnik commented Apr 27, 2017

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 comment has been minimized.

deontologician commented Jan 25, 2018

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

This comment has been minimized.

Contributor

glaebhoerl commented Jan 25, 2018

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

This comment has been minimized.

Contributor

rpjohnst commented Jan 25, 2018

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

This comment has been minimized.

Contributor

glaebhoerl commented Jan 25, 2018

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

This comment has been minimized.

Contributor

rpjohnst commented Jan 25, 2018

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

This comment has been minimized.

Contributor

glaebhoerl commented Jan 25, 2018

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

This comment has been minimized.

deontologician commented Jan 26, 2018

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

@glaebhoerl

This comment has been minimized.

Contributor

glaebhoerl commented Jan 26, 2018

@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

This comment has been minimized.

deontologician commented Jan 26, 2018

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

This comment has been minimized.

Contributor

jonhoo commented Apr 27, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment