return x; and x not equivalent at end of function?

[lheckemann]

I have some code which the borrow checker doesn't agree with. However, it works fine if I replace the expression at the end of the function with a return statement containing the same expression. I believed that return x; was fully equivalent to x at the end of a function, but apparently not? Not sure if this is a documentation issue or a compiler bug, but after raising this on #rust-beginners it was recommended that I raise it here :)

[arielb1]

They are not equivalent. The destructor for possible.drain() runs earlier in the return version and later (too later) in the no-return version.

[lheckemann]

In that case I think this is a documentation issue. https://doc.rust-lang.org/reference/items.html#functions suggests that they are equivalent:

Every control path in a function logically ends with a return expression or a diverging expression. If the outermost block of a function has a value-producing expression in its final-expression position, that expression is interpreted as an implicit return expression applied to the final-expression.

[arielb1]

That paragraph is actually sort-of correct - what matters is whether there's a semicolon (making for a return statement) or not (see https://play.rust-lang.org/?gist=763b754c7393eb72d3d8b79721dba3ba&version=stable - a non-semicoloned return expression.

OTOH, that reference section is entirely a lie for several reasons. Let's fix it

[ghost]

The destructor for possible.drain() runs earlier in the return version and later (too later) in the no-return version.

But why isn't this applied though?
note: values in a scope are dropped in the opposite order they are created

If it happens that the lifetimes of both 'possible' and 'possible.drain()' end at the same point(when function scope ends?), then shouldn't they be dropped in the opposite order they are created.

Why does The destructor for possible.drain() run later (too later) in the no-return version. ?

EDIT: well, nevermind this, I guess there are more pressing issues like rust-lang/rfcs#811 which may or may not affect this when fixed.

EDIT2: thanks to oli_obk for linking me to the old 2015 issue here #21114 (comment)

[ghost]

the code in OP is now working by prepending the line #![feature(nll)] (Rust nightly required, currently)

now, let me just take a moment to praise the NLL gods... 🥇