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.

upvote for rust errors being finicky

I've seen some odd reusability being possible with if statements... can't remember what situations. maybe it was using Copy. I figured I was using a value and wouldn't be able to use it again because the if wrap consumed it already but it let me use it. can't remember what the statement exactly was (damned brain damage)

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.

@lorentz no it's like a if let Some and it takes a value out of a struct. but then under the if branch that did this I used other variables in the struct

something like that

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

@lorentz oh that's great

hmm I think there are a bunch of side rules though. I had issues with structs before when it came to mut versions of them. oh ok so that sort of makes sense. because I wasn't taking a value out of it as mut, it didn't hold the whole struct hostage and I could take some sub value out as mut I guess. idk seems a little suspicious, cuz if one mut is out you can't ref values 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