In the following code "in match" is outputted before "drop". I naively expected that it would be the other way around because the scope of the temporary "Foo" would end before entering the match block. Can someone explain this behaviour? Playground struct Foo; impl Drop for Foo { fn drop(&mut …

Temporaries from the expression that you match on live until the end of the whole match ... {} expression. The rules about when temporaries are dropped are in-deed a bit arbitrary; for match this can be important in cases where the temporary is borrowed and that borrow is used inside of the match. B…

I think it’s informative to compare this behavior vs a version of foo() that takes Foo by value, where drop happens before “in match”. A match expression has to last as long as the match block in case you make bindings to the value (in this case derived from a reference to a temporary), although it…

[image] JosephOsborn: A match expression has to last as long as the match block in case you make bindings to the value (in this case derived from a reference to a temporary) Here's a modification of your example to illustrate such a binding. (Note that in a more complicated match, multiple a…

[image] steffahn: The rules about when temporaries are dropped are in-deed a bit arbitrary; for match this can be important in cases where the temporary is borrowed and that borrow is used inside of the match. Makes sense. I just assumed that the compiler could prove that the type of the expr…

[image] rippz: I just assumed that the compiler could prove that the type of the expression does not borrow the temporary. Oh, I would personally love if it did something like this. The common counter-argument is that people want drops to be very predictable because things like e.g. using uns…

Yeah that would be a very nasty subtle change to introduce. Even when guarded behind an edition it would be a massive PITA to port existing code to.

There was some related discussion about temporary lifetime inconsistency in this recent thread: [image] While let borrow lifetime seems to be too long help Hello, By my reasoning, the two while let -loop headers in the program below should be equivalent, but the commente…

I certainly think it would be a bad idea to let drop locations depend on type information such as lifetimes.

I wouldn't think it's that negative. When you use Rcs, the drop location even depends on runtime information. I don't like implicit drops that have very relevant visible effects anyways, and other situations, e.g. where drop just does deallocation, the worst effect you can get from a surprising time…

I guess if things go that way, drop(x) can always be used to delay a drop by extending lifetime where it matters as easy as it can shorten a lifetime currently.

std::mem::drop is your best friend, if you want to ensure something is dropped at a certain location. I do use it for pragmatics, sometimes, e.g. when constructing an instance from a raw pointer and I only construct it to drop it, afterwards.

Why is drop called after the match block?

mbrubeck November 1, 2020, 10:05pm 8

There was some related discussion about temporary lifetime inconsistency in this recent thread:

Topic		Replies	Views
Why does the temporary in the last statement is dropped after the local variable? help	30	1287	October 12, 2023
Variable scopes extend beyond the match expression help	4	1301	October 30, 2020
Why does match keep temporary values in scope through arms? help	6	1051	November 25, 2020
Drop rules for temporaries in final expression help	3	509	February 15, 2021
Drop semantics and temporary value lifetimes in while let help	16	3856	August 3, 2019

Why is drop called after the match block?

Related topics