-
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
Standardize on self-containedness of examples in docs. #9403
Comments
I would actually put my vote in for the first because otherwise we'd have to duplicate the same |
This is really a tangent, but I note that the |
It would be a bad pattern if we had to repeat the name of the module (and even the name of the crate) in each example. |
I prefer the first. I'd prefer to have some sort of header or standard template that can be modified, that doesn't show up in docs. Docs are primarily for showing how to do something simply. Something like how |
I think there are some types of examples (cross-crate, etc.) that would be very hard to get working inline at all, as we've seen with rusti. We would also be unable to assert that, e.g., particular output happened with a convention-based approach. I think a good option might be to maintain the examples as sets of tests, which can be required to pass or fail as needed. Any code that is supposed to show up in the example would need to be wrapped in a block of some sort with metadata specifying that it was an example. We could then use our existing test infrastructure to parse the examples (which could do anything our tests could do) and, if they passed, import the examples. The only downside I can think of is that the examples wouldn't be inline with where they showed up (initially, I mean, not in the final result), but I think that's probably unavoidable to some extent for examples that span multiple files. |
I think that the answer is 'link to the playground with a full example'. |
I agree. |
I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized. This issue has been moved to the RFCs repo: rust-lang/rfcs#688 |
match_wild_err_arm: Fix typo in note text changelog: [`match_wild_err_arm`]: fix typo in note text
There are many examples in the docs that require some adjustments to get to compile, e.g. the following requires a
main
function:(
Iterator.chain
at the time of filing.)And others that are entirely self-contained, and can just be copy-pasted to be run.
(One of the examples at the top of
std::rand
.)It seems like it would be good to be consistent about this. I prefer the latter, and it would make automatically running the tests much easier (#2925).
The text was updated successfully, but these errors were encountered: