-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Improve the tuple and unit trait docs #97842
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
r? @m-ou-se (rust-highfive has picked a reviewer for you, use r? to override) |
CC @rust-lang/rustdoc |
I like the idea, but I'm not convinced by the approach here as I have no idea just from the reading the docs that it is also applied to Also it seems a bit strange to have only But I really think it's a good start! |
@GuillaumeGomez What do you imagine a good approach to this would look like? |
I honestly have absolutely no idea. Providing this information unambigously and efficiently is gonna be the hard part I think. |
Perhaps |
I'm not sure either but yeah I do feel this is an area that could handle improvement. I think |
So, custom unstable attribute that changes the presentation of tuples? |
I think
|
This commit adds a new unstable attribute, `#[doc(tuple_varadic)]`, that shows a 1-tuple as `(T, ...)` instead of just `(T,)`, and links to a section in the tuple primitive docs that talks about these.
Before: impl<T, U> UnwindSafe for (T, ...) where T: UnwindSafe, U: UnwindSafe, After: impl<T> UnwindSafe for (T, ...) where T: UnwindSafe,
@jsha Okay, here’s a new version with that idea implemented. It does look quite a bit better. |
(I realize I'm being pedantic 😄 ) In the "Trait implementations" subheading:
But in the
Instead, the subheading could say
or outright state that it's a length of twelve except for |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The display and the text are looking good to me. Just to check: are the demo links up to date?
A note on consistency: the current demo has:
impl<T: Clone> Clone for (T, ...)
impl<T11> Debug for (T11, ...)
impl<L> Default for (L, ...)
impl<A> Hash for (A, ...)
I haven't fully grokked the macros yet, so it's not clear to me where the T
, T11
, L
, and A
are coming from. It would be nice for them to be consistently T
unless the other type variable names mean something.
31c35c5
to
e78950b
Compare
Co-authored-by: Jacob Hoffman-Andrews <github@hoffman-andrews.com>
e78950b
to
c148755
Compare
I like the idea of using Unicode ellipses. Maybe, to avoid being overly verbose, it could use subscripts in the tuple, but not elsewhere?
|
Yeah, I think that works well! |
|
Hm, that might result in people wondering what the But I don't have a strong opinion either way. It could also work nicely. :) |
Mathematical notation overload. :D |
I like this version. And the detail that T's bound must apply to each Tₙ individually can be explained in the linked paragraph in the documentation. |
Okay, I've update the uploaded docs page to have the new unicode presentation: https://notriddle.com/notriddle-rustdoc-test/std/primitive.tuple.html#impl-Copy |
Looks almost all good to me. Can you add a test for the notation as well please? |
Looks good to me, thanks! |
Let's go then. Thanks everyone for the feedback! @bors r=jsha,GuillaumeGomez |
📌 Commit f1d24be has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (6ec3993): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
…rochenkov,GuillaumeGomez Improve the function pointer docs This is rust-lang#97842 but for function pointers instead of tuples. The concept is basically the same. * Reduce duplicate impls; show `fn (T₁, T₂, …, Tₙ)` and include a sentence saying that there exists up to twelve of them. * Show `Copy` and `Clone`. * Show auto traits like `Send` and `Sync`, and blanket impls like `Any`. https://notriddle.com/notriddle-rustdoc-test/std/primitive.fn.html
@@ -125,4 +156,4 @@ macro_rules! last_type { | |||
($a:ident, $($rest_a:ident,)+) => { last_type!($($rest_a,)+) }; | |||
} | |||
|
|||
tuple_impls!(A B C D E F G H I J K L); | |||
tuple_impls!(E D C B A Z Y X W V U T); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason for this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it’s so that the tuple docs consistently show (T…)
instead of (L…)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't s/L/T
suffice then? The letters seem random...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would work, yes.
I think `impl Foo for (T, ...)` is good. The `(T, ...)` part should link to
a subheading of the tuple page's top-doc that say, approximately, "In this
documentation (T, ...) is used to represent all tuples up to length twelve.
In such constructions, any trait bounds expressed on T apply to all fields
of the tuple. Not that this is a shorthand, not valid Rust syntax."
|
(T,)
and include a sentence saying that there exists ones up to twelve of them.Copy
andClone
.Send
andSync
, and blanket impls likeAny
.Here's the new version: