RFC: Pattern Guards with Bind-By-Move

[zwarich]

• Rendered view
• Tracking issue
• Stabilization PR

[huonw]

What is the validity of these:

// A
match x {
    A(v) if { drop(v); true } => 1,
    _ => 2
}
// B
match x {
    A(v) if { drop(v); true } => 1,
    A(v) => v.len() 
}
// C
match x {
     A(v) if true => v,
     A(v) => v
}
// D
enum Foo { X(Box<int>), Y }
match some_foo {
    X(b) if { drop(b); true } => (),
    Y => {}
    _ => {}
}

I assume that A, C and D are valid, but B is not.

(I ask these since all your examples have only one non-_ arm, and there's no example that's valid and that moves out in the guard itself.)

[Florob]

@huonw Is that based on the assumption that a value is not moved, when it is not used in the match arm? That is not currently the case. I would expect only C to be valid, since all others move into the match arm and inside the pattern guard, equivalently to the rejected example in the RFC.

[zwarich]

@huonw No moves of a bound-by-move value would be permitted in the guard, because there is a move between the guard and the expression, and any move in the guard would result in a double move. The only example that would be valid is C. Maybe I'll update the examples in the RFC to mention this.

[kmcallister]

+1, this would be very useful to me in the HTML parser, e.g.

token @ StartTag(ref tag) if named!(tag, html)
    => self.step(states::InBody, token)  // pass by move to another state

[nikomatsakis]

This has definite interaction with the plans to remove zero flags.

[zwarich]

@kmcallister, your exact example would also need nonlexical borrow scopes to be accepted. With the current system, the borrow for ref tag would conflict with the move into token.

[zwarich]

@nikomatsakis, what is the interaction with removing zero flags here? Removing zero flags will require checking that each control-flow merge point has the same moved paths. Since there is no new move here (just clarification about when it occurs), I don't see how it could complicate anything.

[alexcrichton]

This was discussed at a recent meeting and it was concluded that we would like to merge this with the condition that a feature gate was mentioned in the RFC.

The RFC has been updated, so I'm merging.

[eminence]

Now that this RFC is merged, the above "rendered view" link is broken. The text of this RFC can now be found here:

https://github.com/rust-lang/rfcs/blob/master/text/0107-pattern-guards-with-bind-by-move.md

[Pzixel]

Any ideas/progress on that? I think this is perfectly valid code:

fn f(x: Option<String>) {
    match x {
        Some(a) if &a == "Hello" => println!("x is Hello"),
        Some(b) => println!("x is not Hello but {}", b),
        None => println!("none"),
    }
}

But borrowcheker currently won't accept it

The thumb rule here is if we only use matched values by-reference they could be logically moved back to x if guard didn't pass the check.

[CryZe]

This works just fine in 1.39, which is currently in Beta.

[Pzixel]

Wow, guys, you're so quick.

I wonder if I ask about GAT and they appear in 2 minutes thereafter... 😄