Don't discriminate unions and structures and enums

[nox]

Unions, structures and enums are all different kinds of data, but I don't think it makes any sense to discriminate them in the documentation.

Whenever I explore the documentation of a crate, I don't know if the concept I'm looking for is an enum or a structure, but I most often have a vague idea what it is named, and I don't want to look at multiple lexicographically ordered lists to find it.

I suggest we make a single list of "data items", with all structures, enums and unions lexicographically listed.

[RalfJung]

Would it make sense to include type aliases as well?

Types, functions and macros form three disjoint namespaces in Rust; I think it would make sense for documentation to follow the same structure.

[nox]

@asajeffrey was of the opinion that they should be included too, I'm on the fence for them but I don't have any counter-argument and the fact they share the same namespace as the actual data items (for lack of a better term) is a good argument in favour of including them too.

[asajeffrey]

Does it make sense to treat type aliases the same as re-exports?

[Centril]

I frequently discriminate between enums and structs when looking at rustc internal docs. For example, an enum is often a ***Kind of some sort. If we merge them it would be nice to have some sort of filtering mechanism in the searches, e.g. by searching for :enum thing.

[est31]

it would be nice to have some sort of filtering mechanism in the searches, e.g. by searching for :enum thing.

IIRC this should already work. You search for enum:thing or fn:thing and it only returns enums/fn's named that way. At least in theory. It's explained in the help screen when you press ? or here in the source code.

[Centril]

@est31 oh neat, TIL.

[lu-zero]

Ideally searchability should be improved, see #61190 for an example.

[nox]

Where would one need to start to do such a change? Cc @GuillaumeGomez

[GuillaumeGomez]

You already have a list of all items. Also, different types can have the same name. For me, it seems better to keep it this way.

[RalfJung]

You already have a list of all items.

Which list do you mean?

Also, different types can have the same name.

An enum and a struct cannot have the same name just like two structs cannot have the same name -- only if they are in different modules. So what do you mean by "different types can have the same name"?

[GuillaumeGomez]

Which list do you mean?

https://doc.rust-lang.org/nightly/std/all.html for example. There is a "see all items" button in the root module file.

An enum and a struct cannot have the same name just like two structs cannot have the same name -- only if they are in different modules. So what do you mean by "different types can have the same name"?

Sorry, I had in mind the insensitive naming in mind... Then I just didn't understand the issue (and still don't).

[nox]

Sorry, I had in mind the insensitive naming in mind... Then I just didn't understand the issue (and still don't).

This issue is about merging the list of structs, enums, unions and types on this kind of page.

[nox]

(Because there is no reason for Expr to be that far away from ExprIf, for example.)

[GuillaumeGomez]

Ok, now I understand. Well, I personally don't care much about this but if other @rust-lang/rustdoc people agree with this, I'm fine adding it. Just one note though: I'd like to keep the color code.

As a sidenote: I could add a new setting in order to have this enabled/disabled depending on users. That could allow us to see if people like it enough to make it the default.

[nox]

Ok, now I understand. Well, I personally don't care much about this but if other @rust-lang/rustdoc people agree with this, I'm fine adding it. Just one note though: I'd like to keep the color code.

Why keep the color code? I sometimes have to wrap my union types in structs just so they appear like plain old structs, because the fact that they are unions is an implementation detail.

Why is it useful for end users to know that MaybeUninit is an union, for example?

As a sidenote: I could add a new setting in order to have this enabled/disabled depending on users. That could allow us to see if people like it enough to make it the default.

That means more JS, and such settings often break for me on docs.rs.

---

On a more general note about this suggested change, I feel like if the discrimination had never been there in the first place, no one would miss it.

[GuillaumeGomez]

We have the color code everywhere. It wouldn't make sense to remove it from here. People might not care about the type, but at least they can have an idea when looking at the color. Having it isn't an issue whereas the opposite might be.

That means more JS, and such settings often break for me on docs.rs.

I agree on this but unfortunately, this is a "big" thing you're asking for. Getting an agreement on this might take a while, it was just an idea I had in order to shorten this gap.

[nox]

It is not that "big" of a thing: it's a fix. The discrimination can lead users to believe structs, enums, type aliases and unions live in different namespaces when they are not.

As for the colours, I'm not suggesting we remove them entirely, I'm suggesting we don't use different colours for things in the same namespace.

[nox]

We don't colour procedural macros and macro_rules macros differently.

[GuillaumeGomez]

It is not that "big" of a thing: it's a fix. The discrimination can lead users to believe structs, enums, type aliases and unions live in different namespaces when they are not.

It is that big of a thing: it's a UI change. Also, you're the only one until now that seemed to have this issue. I never heard users saying that they thought because of that they different types lived in different namespaces.

We don't colour procedural macros and macro_rules macros differently.

It's another debate.

[RalfJung]

@nox is not alone asking for this change here in this thread.

Is there procedure for how to get consensus on rustdoc changes?

[GuillaumeGomez]

I said I accepted this change under the conditions I gave. We're debating the conditions as far as I can tell.

[nox]

There are four other persons in @rust-lang/rustdoc who didn't chime in.

[GuillaumeGomez]

We are four. :p Also I can always put my veto so not really a better way of handling things... But I'm curious what they think about this change.