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.

[Gankro]

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

[nikomatsakis]

triage: P-medium

[eddyb]

It would be very helpful to point out the error, which is:

<anon>:8:9: 8:10 error: mismatched types:
 expected `str`,
    found `collections::string::String`
(expected str,
    found struct `collections::string::String`) [E0308]
<anon>:8     f(&{x}); // Error
                 ^

So the problem could be that str propagated through the block to x, despite being unsized.
As blocks are always rvalues, maybe the "expected type" propagation doesn't deal with unsized values being mere hints in the block case?

[eddyb]

Update: That was dumb of me: I did not realize this only ever happens with str.
Of course it does, because I never implemented it.