Matching Box(<pattern>) against Box<T> should give privacy error, not type mismatch

[shepmaster]

While looking at #22205, I tried this as a workaround:

struct NonCopy;

fn main() {
    let x = Box::new(NonCopy);
    let Box(y) = x;
}

However, this has the error:

<anon>:5:9: 5:15 error: mismatched types:
 expected `Box<NonCopy>`,
    found `alloc::boxed::Box<_>`
(expected box,
    found struct `alloc::boxed::Box`) [E0308]
<anon>:5     let Box(y) = x;
                 ^~~~~~

[huonw]

Other than the rather strange error message, this isn't a bug (at least, there's no reason it should work). The Box struct is defined like

struct Box<T>(Unique<T>);

so a Box(y) pattern is trying to bind y to the Unique<T> pointer, not to the T itself.

It should be failing with a privacy error, like:

pub mod foo {
    pub struct Bar(i32);
    impl Bar {
        pub fn new(x: i32) -> Bar { Bar(x) }
    }
}

use foo::Bar;

fn main() {
    let x = Bar::new(1);
    let Bar(y) = x;
}

<anon>:12:13: 12:14 error: field #1 of struct `foo::Bar` is private
<anon>:12     let Bar(y) = x;
                      ^

[pnkfelix]

See also #22045, which argues that we might want to be able to put a separate Box entity into the value-namespace, and leave the existing box solely in the type-namespace (i.e., change it to a non-tuple struct), which would change the expected error message here.

But yeah, I wouldn't be at all surprised if this were a consequence of the current special treatment of Box in the compiler.

[florence]

FWIW, I work around this by using #![feature(box_syntax)].

let box y = x;

compiles just fine.

[steveklabnik]

Triage: still giveing the original error, rather than a privacy error.

[Mark-Simulacrum]

This now gives a privacy error; I don't think we really need a test here. Closing.