Open
Description
It seems that the compiler handles a block differently when coercing a value.
fn f(_: &str) {}
fn main() {
let x = "Akemi Homura".to_owned();
f(&x); // OK
f(&(x)); // OK
f(&{x}); // Error
}
RFC 401 says that a block with type U
is also a target for coercion, so I think this behavior is a bug.
blocks, if a block has type
U
, then the last expression in the block (if it
is not semicolon-terminated) is a coercion site toU
. This includes blocks
which are part of control flow statements, such asif
/else
, if the block
has a known type.
Also, the compiler seems to be able to coerce blocks using some "trivial" rules (e.g. &mut T
-> &T
).
fn f(_: &i32) {}
fn main() {
let x = &mut 42;
f(x); // OK
f((x)); // OK
f({x}); // OK
}
So I guess this is more likely a problem of auto-deref.
Activity
Gankra commentedon Jul 11, 2015
CC @nrc
bluss commentedon Jul 12, 2015
As some users have discovered,
{x}.item
can be used to force ax: &mut X
to move instead of reborrow. Is that related? We might not be allowed to break that.[-]Auto-deref does not work with blocks[/-][+]Deref coercions do not work with blocks[/+]nrc commentedon Jul 12, 2015
I suspect this is something specific to deref coercions. I think it is 'just a bug', but I don't know how easy it is to fix.
tbu- commentedon Aug 20, 2015
This blocks usage of
try!
together with deref coercions if I understand this bug correctly:let _: &Path = &try!(env::current_dir());
fails to compile.barosl commentedon Aug 21, 2015
@tbu- Yup, actually this issue was found by a Stack Overflow question that tried the same thing.
llogiq commentedon Sep 19, 2015
There is also this rust-users thread with a very similar problem.
nrc commentedon Sep 21, 2015
triage: I-nominated
nrc commentedon Sep 21, 2015
triaged because it is such an annoying bug. Recommend p-medium.
nikomatsakis commentedon Oct 1, 2015
cc @eddyb
19 remaining items