rustdoc: Remove Derived Implementations title #34105
Conversation
As far as I know whether a trait was derived or not does not change the public API so there is no need to include this information in the docs. This title currently just adds an extra divide in the list of trait implementations which I don't think needs to be there.
|
r? @cmr (rust_highfive has picked a reviewer for you, use r? to override) |
|
Hmm I don't agree, because when an impl is derived you know exactly what it does, as opposed to a manual impl which may be customized. |
|
Initially added in #12961 there's a little bit of discussion there, but not a lot. I think historically the impl section was much more noisy than it is today which was the original motivation for that, so the initial rationale may no longer be applicable. I agree with @durka that this does serve a nice indicator that the implementation wasn't touched and you may be able to rely on that, but on the other hand @ollie27 is right in that it's just visual clutter because that's not really applicable for knowing the API of a type. Whether or not it was strictly implemented via As a result I'd personally be in favor of this, but would be curious what @steveklabnik and other docs folks think as well. |
|
I'd like to have a live version to see the change directly. Could you add it please? |
|
Sure, why not, there you go: https://ollie27.github.io/rust_doc_test/ Some nice examples: |
This is the way that I feel about it. This feels like a violation of encapsulation to me, but I also don't care enough to block it; if others feel it's useful, I'm okay with it landing. |
|
I like this change! 👍 |
|
@steveklabnik note that this is removing the difference between sections, whereas currently there is a special "derived implementations" section. Sounds like that's what you'd favor though? |
|
📌 Commit cc18104 has been approved by |
|
⌛ Testing commit cc18104 with merge 03ab565... |
…hton rustdoc: Remove Derived Implementations title As far as I know whether a trait was derived or not does not change the public API so there is no need to include this information in the docs. This title currently just adds an extra divide in the list of trait implementations which I don't think needs to be there.
|
⛄ The build was interrupted to prioritize another pull request. |
|
⌛ Testing commit cc18104 with merge 47695a1... |
|
⛄ The build was interrupted to prioritize another pull request. |
|
⌛ Testing commit cc18104 with merge bae0709... |
|
⛄ The build was interrupted to prioritize another pull request. |
|
⌛ Testing commit cc18104 with merge d6de998... |
|
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
|
@bors: retry |
|
💔 Test failed - auto-linux-64-x-android-t |
|
@bors: retry |
|
💔 Test failed - auto-linux-64-x-android-t |
|
@bors: retry On Wed, Jun 29, 2016 at 9:09 AM, bors [email protected] wrote:
|
|
@bors: retry |
|
⌛ Testing commit cc18104 with merge 319138d... |
|
💔 Test failed - auto-linux-64-opt-rustbuild |
As far as I know whether a trait was derived or not does not change the
public API so there is no need to include this information in the docs.
This title currently just adds an extra divide in the list of trait
implementations which I don't think needs to be there.