-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mark std
integral modules as deprecated (std::u32
, std::i16
, etc.)
#107587
base: master
Are you sure you want to change the base?
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
While this does remove some confusion, it also adds confusion. Someone might be reading old code and see |
I agree it could add confusion in addition to breaking legacy links to these items. I think it would be better to have rustdoc exclude or derate deprecated items for search engines if that is a major concern. I see the other discussion now. One option not brought up there is making the canonical links for deprecated items point to the replacement. |
Currently there is no indication that an item is deprecated in the rustdoc search results. That could also be improved as currently |
I think they can be deprecated now, the MSRV concerns are gone, even debian 11 has rustc 1.43. I don't think one should completely hide the files from the docs. One could think about changing rustdoc's search results to show if an item was deprecated. To do SEO to make the constants not appear in google searches for "i32 max" that's tougher. I think the issues were correctly identified on zulip, google prefers to link to "dedicated" pages where the name is part of the URL instead of "collection" pages where the thing is just a section in the page. The associated consts do not have dedicated pages, while One could maybe add a Generally I'm not a fan of hiding too much deprecated stuff though, because there are use cases that benefit from having pages even for deprecated items show in search results. E.g. if it's not as simple as in this instance, if the renamed item is called differently, and you are during a migration from deprecated items to their new equivalents, then you might be interested in the rustdoc page for the deprecated item. I think most people would use rustdoc's builtin search, but some might also expect Google's search to work.
It would generally be good to be able to run rustfix on deprecated items, if there is a 1:1 correspondence to an API in another place (it's just been a rename). See also rust-lang/rustfix#151 with some discussion about this. |
Maybe there's been a misunderstanding. When I was talking about canonical links, I was talking about URL Canonicalization. This would essentially mark the But maybe you were just saying that it could use the same metadata as rustdoc. In which case, I agree. |
@pitaj using canonical pages feels like a hack to me as Reading the discussion in #107579, i doubt that mirrors like mit.edu will be shown instead if you add a noindex tag. Google already now shows the right page right below the Another idea would be to add |
@pitaj said:
That won't work. When search engines process There are three problems here:
(1) and (2) cannot be fixed by any noindex or search engine changes. (1) can only be fixed by (2) is not made better or worse by moving these modules from TBD-deprecated to actually-deprecated. In my mind, (2) is the worst of these problems. In a few minutes I found three different threads from confused users asking why Rust is deprecating the integers: |
Alright, canonicalization isn't going to work. Is there a way to hide the modules from "discovery" (hide them from the module list) without hiding the actual docs (still allow directly navigating to the page and show them in rustdoc search)? That would solve (1) and (2) directly, and perhaps hiding them from search engines (3) could be attached to that same flag. A separate flag may not be necessary, maybe it's tied to whether the deprecation has a direct replacement. |
@jsha put it quite succinctly, thanks for the summary. I think there has to be a path forward to remove these items from the module listing and search engine results to help new users. It's very likely that new users stumble across these pages / module listings and get confused - this is cited a few places. I believe it's much less likely that somebody trying to understand old code actually goes to the documentation to verify what It is important to note that hiding items from the docs should not be a precedent for basically anything. This is a special exception that needs to be addressed, because this is a pretty awful user experience to have on the main docs landing page:
That sounds like a great option to me, perhaps via a There is an open issue for decreasing the rank of deprecated items within the rustdoc search, but it hasn't gotten any attention: #98759. That would also help things When I get the chance, I'll change the PR contents to only deprecate the items without hiding them, then open a separate issue for adding something like |
Adding a It'll need to go through at least FCP since we're adding a new feature but otherwise sounds good to me. |
Hi @pitaj |
This comment was marked as off-topic.
This comment was marked as off-topic.
FWIW, I don't think |
But that allows to keep links to these items to continue to work. Also, it can come in handy for the duplicates between |
My other thought was something like But I do think
So all in all it seems like a good solution for things that you don't want to explicitely promote, but also don't want to make completely impossible to view. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Two further proposals to improve the situation, that might be enough on their own to not need changing the titleGoogle's search results reproduce the title in the most prominent position. If you google for "rust u32 max", you are shown a top level link with the title "MAX in std::u32 - Rust". What about changing rustdoc to include the fact that the item is deprecated in the title? Maybe "MAX (deprecated) in std::u32 - Rust"? It shouldn't be the first word as when you have many tabs open with deprecated items, then it will remove the rightmost parts first, so you might get into the situation where you have multiple tabs with "Deprec", "Deprec", "Deprec" as substrings of "Deprecated MAX in std::u32 - Rust". I think this might actually improve the situation for all deprecated items. changing the module-level docsRight now it only indicates the difference from the native types indirectly: One could make it more explicit that the construct here is a module by mentioning it directly in the first line, and not the type: The confusion about rust deprecating the type instead of the module is probably partially caused by the fact that both module and type have the same name down to the casing.
|
I like @dtolnay's ideas about taking a non-deprecation approach to this. For users, it's not clear that deprecating these constants solves a problem. And it introduces some other rather complicated problems - like how to present the deprecation information without making it look like the primitive types themselves are deprecated. To the extent the deprecation solves a user problem, it's this from RFC 2700:
(today it's 12 out of 67, 18%) I think this is not a large problem. It's still very straightforward to skim the list of modules in std, and it's easy to see that all the integer modules are related to each other and skim past them. On the other hand, attempting to solve this documentation problem is a big deal because it requires us to create a new category of item that is both deprecated and hidden. Right now we don't hide deprecated items from the documentation, because those items are used in running code and people need to find out what they do. I propose not deprecating, and removing the |
We discussed this briefly in the libs-api meeting again. We think it might be valuable to have a (clippy) lint for this. (And then later uplift it to rustc.) |
Nit/bikeshed: |
Opened a clippy issue for this: rust-lang/rust-clippy#10995 Planning on working on it in the coming weeks but if someone else wants to jump on it, go right ahead. |
@SnoozeThis rust-lang/rust-clippy#10995 && wait 4 months Let's revisit this after the clippy lint has been around for a while. |
(https://snoozeth.is/XWplGyz9_wI) I will wait until rust-lang/rust-clippy#10995 is closed and wait until Fri, 27 Oct 2023 15:53:04 UTC and then add a comment. |
@rfcbot fcp cancel |
@dtolnay proposal cancelled. |
☔ The latest upstream changes (presumably #121295) made this pull request unmergeable. Please resolve the merge conflicts. |
Resolved. |
The clippy lint has just been merged (rust-lang/rust-clippy#12312 (comment)), so I suppose now we should be waiting 4 months to see it spread in the ecosystem. August 1st 2024? @SnoozeThis wait 4 months |
(https://snoozeth.is/HLD_dIaUAH0) I will wait until Wed, 31 Jul 2024 23:17:59 UTC and then add a comment. @rustbot claim. |
@rustbot author Please rebase and update |
Search for allows of that lint yields only 11 results. |
This PR seeks to officially deprecate the number modules in
core
andstd
, which is the last remaining open item on #68490. It also marks them as#[doc(hidden)]
to avoid confusion.Motivation
The main reason to hide the documentation rather than just deprecating is user confusion: it seems like users have not infrequent questions about why Rust is deprecating integers (@Nilstrieb mentioned in chat and @jsha linked in this comment #107579 (comment)).
It also isn't great for the optics of language stability that the first result for some common-ish searches link to a page stamped with "deprecation planned" all over.
Jsha linked this relevant RFC, which indicates that removing these modules from the docs was part of the original plan: #107579 (comment)
Links:
Newly deprecated & hidden modules
core::u16
core::u32
core::u64
core::u128
core::usize
core::i8
core::i16
core::i32
core::i64
core::i128
core::isize
core::f32::{DIGITS, EPSILON, INFINITY, MANTISSA_DIGITS, MAX, MAX_10_EXP, MAX_EXP, MIN, MIN_10_EXP, MIN_EXP, MIN_POSITIVE, NAN, NEG_INFINITY, RADIX}
core::f64::{DIGITS, EPSILON, INFINITY, MANTISSA_DIGITS, MAX, MAX_10_EXP, MAX_EXP, MIN, MIN_10_EXP, MIN_EXP, MIN_POSITIVE, NAN, NEG_INFINITY, RADIX}
std
reexports of these modules & constsThe float modules are a bit weird since all the constants mentioned above are redundant, but they also contain the
core::{f32, f64}::consts
modules, and these do contain information that isn't available elsewhere (constants like E, PI, SQRT_2, etc). A good long term plan could be to re-export the contents ofconsts
into their parent modules off32
andf64
, then deprecate theconsts
module. There is some more discussion of this in the original post at #68490, but no decision is needed here at this time.Alternatives
If the team is still against full deprecation (as indicated in the old zulip thread), I think it at least makes sense to still mark the items
#[doc(hidden)]
to help resolve the user confusion mentioned above.cc @bstrie, original author of the RFC
@rustbot label +T-libs-api