I'd had some weirder experiences with Rust where errors would surface late or in odd places so now I can't tell whether this is actually legal or the error is being discarded because it's in dead code.

When did Rust start extending the lifetime of temporaries outside enclosing blocks to match their borrows?

(in case it''s not obvious, pattern and full_pattern are both slices)

I was also under the impression that borrow checking didn't affect behaviour at all. For this to be legal, rust has to

- save the boolean

- lift the vector out of the conditional block (into I guess a MaybeUninit?)

- add a new conditional later to deallocate the vector

That is surprisingly complex generated code from a language whose profile is minimal magic just to save me the hurdle of putting the vector in an option and then branching on it.

I'm aware of static promotion but that's for a single lifetime. If I can rely on this for all lifetimes that will be huge.

@jestdotty You can certainly use the same value in an if and its corresponding else branch, that's always allowed. Other than that, I think thhere are a lot of hheuristics in the compiler that specifically target simpler cases not caught by the general algos. I wish they weren't as common, I try to think ahead and phrase my code in a way that the compiler will predictably understand before I type it, and these sometimes lead me astray. There are a lot more of them about trait solving though, this is the first piece of lifetime magic I encountered in a long time.

@jestdotty From what I can tell, structs with no explicit Drop implementations kind of act like a bag of values that you can remove and replace at will. Not sure though, I don't fully understand the rules around method calls on these struct either.

I have no time to read all. I'm wastingy last percent of battery with this.

That was a tension moment. Was almost sweating. It was slowly posting.

@retoor philistine