convention issue: structs with all pub fields are a hazard and should be avoided in libstd

[pnkfelix]

Tuple structs are convenient at times, but they present issues for forward compatibility, especially (but not only) when they carry all pub fields

Example: std::ptr::Unique is currently defined as follows:

#[unstable(feature = "core", reason = "recently added to this module")]
pub struct Unique<T: ?Sized>(pub *mut T);

This is unfortunate, since assuming rust-lang/rfcs#738 is accepted (namely the PhantomData part, which I need for rust-lang/rfcs#769), we really should add PhantomData<T> as a member of Unique<T>.

So, why did we use tuple structs instead of a struct with private named fields?

I suspect it was for the convenience of the person authoring the library when it was first made. But these details end up leaking out to the users of these modules, and there does not seem to be much reason for it. The main use of a tuple-struct in a case like this is for composability with pattern matching, but I do not think that use outweighs the cost of being stuck with an API that hinders future changes to the internals of the stdlib.

---

Another related case where this comes up: we currently define std::boxed::Box as a tuple struct. Now, its only field is non-pub. However, the use of a tuple struct here puts Box itself into the value namespace, and thus the name Box in the value namespace of the prelude is essentially unavailable for any useful purpose. I think this is a bug in that API design; see my comment here: rust-lang/rfcs#809 (comment)

UPDATE: I have been convinced that tuple structs with a non-pub field are not a real hazard (see reasoning in my comment below).

[pnkfelix]

(not sure if this belongs here or in the RFC's repo, but I definitely want it to get attention before the beta release.)

[pnkfelix]

cc @aturon

[pnkfelix]

cc @nikomatsakis (whom I think has similar concerns regarding the over-use of tuple-structs in libstd).

[edwardw]

cc me

[pnkfelix]

actually, maybe a tuple struct with some non-pub fields is still not an issue for forward-compatibility, if it is true that it is always sound to replace such a tuple struct definition with a non-tuple struct definition, by the logic that the client-side end user could not have actually been invoking the constructor that had been put into the value namespace.

[Gankra]

The proliferation of tuple structs is imo the consequence of wrapping and newtyping being tedious. foo.0.blah() and foo = Blah(bar) are nicer to deal with than the struct equivalents. The "anonymous" 0 field is also easier to recall than some random name that made sense at the time (inner? ptr? buf? data?). I have similar gripes with mandatory names on associated types for one-type traits. e.g. Deref, Iterator, Reader, etc.

[aturon]

@pnkfelix FWIW, I don't think that we've stabilized any public tuple structs in std. I will check.

[aturon]

The only places this shows up publically in std are:

• Unique, which was recently added and has not been stabilized,
• simd, which is wholly unstable and contains tuple structs that represent vectors

[pnkfelix]

@aturon Great! Then it really is just a conventions issue, and not something that requires revising existing code.

(That's assuming that it is sound for one to switch from a tuple struct with private data to a non-tuple struct, which we do have instances of in libstd, such as Box, as I noted above.)