Deref coercions do not work with blocks

[barosl]

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 to U. This includes blocks
which are part of control flow statements, such as if/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.

[Gankra]

CC @nrc

[bluss]

As some users have discovered, {x}.item can be used to force a x: &mut X to move instead of reborrow. Is that related? We might not be allowed to break that.

[nrc]

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-]

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]

@tbu- Yup, actually this issue was found by a Stack Overflow question that tried the same thing.

[llogiq]

There is also this rust-users thread with a very similar problem.

[nrc]

triage: I-nominated

[nrc]

triaged because it is such an annoying bug. Recommend p-medium.

[nikomatsakis]

cc @eddyb