Remove tuple structs with inaccessible fields completely from the value namespace

[ftxqxd]

This would be a very minor change. To give an example of what this would do, the following code would work under this change:

use foo::Foo;

mod foo {
    pub struct Foo(());
}

const Foo: () = ();

fn main() {
    let x = Foo;
}

Currently, it doesn’t because the import at the top conflicts with the const Foo, even though the tuple struct Foo is unusable as a value (because it has private fields). This would be a very minor backwards-compatible change, but would make using tuple structs with private fields less bad (equivalent to a normal struct with private fields, I think). cc rust-lang/rust#22045

[pnkfelix]

I think strictly speaking this change may not be backwards-compatible, because one can write this today:

use foo::Bar;

mod foo {
    pub struct Bar((), ());
    pub fn make_bar() -> Bar { Bar((), ()) }
}

fn main() {
    // can observe (via confirmation at compile time) it is tuple struct 
    let Bar(..) = foo::make_bar();
    // can also observe the number of fields it has
    let Bar(_, _) = foo::make_bar();
}

[pnkfelix]

cc rust-lang/rust#22207

[pnkfelix]

Having said that, I would be interested in going down this path. We can go in baby steps by first disallowing the destructuring-binding forms for tuple structs with inaccessible fields.

---

Thinking about it now, I guess the pattern-matching namespace is related to the value namespace, but they are not equivalent, are they? Maybe that detail means my example is actually not contradicting what this is proposing?

[pnkfelix]

(This is a potentially interesting issue to think about, but not the teensy-small delta to the language I had originally thought, so I took back my nomination for discussion at lang mtg for now...)

[nikomatsakis]

I do not think we can remove from value namespace, but you could imagine making the value namespace entry private. I think it's a good point that you can observe number of fields. That feels wrong.

[petrochenkov]

What about

pub struct S(pub u8, u8);

let S(x, _) = ....;
let S(x, ..) = ....;

?
Intuitively, this should work,

I agree, however, that these "barely usable" constructors restrict library evolution freedom, so it makes sense to "privatize" them for practical reasons.

[petrochenkov]

Workaround for

pub struct S(pub u8, u8);
let S(x, ..) = ....;

is

let S { 0: x, .. } = ....;

this should be on stable soon.

[eddyb]

@whitequark Heh, GitHub acted on your push but not @bors' (maybe @bors should get powers here?).

[whitequark]

@eddyb what on earth just happened?

[eddyb]

@whitequark You have powers on this repo, @bors doesn't. Closing issues cross-repo "just works" then.

[whitequark]

Oh... but I've pushed into a fork. Why did GitHub act on that?..

[eddyb]

@whitequark It might have something to do with the fact that it's on the master branch.

[petrochenkov]

Well, at least the end result is intended - the issue is closed.