-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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 documentation for each. #4305
Conversation
I have updated to include an example of the breaking behavior, as well as made it use the Rust-standard 4 space indent: I'm too used to two spaces. |
* # Examples | ||
* ~~~ | ||
* for [1,2,3].each |&i| { | ||
* io::println(int::str(i)); |
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.
So, this is returning true and continues iterating ? In line 1191 you have an explicit true and that confused me a bit.
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.
It returns ()
(unit).
The difference is actually between the for
and the do
. If you changed this one to do
, you'd get
rustc fizzbuzz.rs
fizzbuzz.rs:2:27: 4:3 error: Do-block body must return bool, but returns () here. Perhaps you meant to write a `for`-loop?
fizzbuzz.rs:2 do [1,2,3,4,5].each |&i| {
fizzbuzz.rs:3 io::println(int::str(i));
fizzbuzz.rs:4 }
error: aborting due to previous error
make: *** [build] Error 101
Maybe making a bigger note of this is a good idea here.
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.
I think thats a good idea. This is implying that both 'for' and 'do' need to return a boolean.
Add description of arguments, and an example.
Updated to not use |
Wouldn't it be better to emphasize the |
Looks good to me 👍 |
@bjz well, for me, API docs should cover just the API that they're covering, and refer to other documentation. Using two things together seems more like tutorial style docs than API docs. I'll do whatever the Rust team wants in this regard. :) |
Looks good to me as is. I know you know, but it should be retargeted against Thanks for doing this and I'd welcome more like it! Documentation patches are wonderful! |
🤘 I've opened a new PR targeting |
Rework use_self impl based on ty::Ty comparison rust-lang#3410 | Take 2 This builds on top of rust-lang#5531 I already reviewed and approved the commits by `@montrivo.` So only the review of my commits should be necessary. I would also appreciate your review `@montrivo,` since you are familiar with the challenges here. Fixes rust-lang#3410 and Fixes rust-lang#4143 (same problem) Fixes rust-lang#2843 Fixes rust-lang#3859 Fixes rust-lang#4734 and fixes rust-lang#6221 Fixes rust-lang#4305 Fixes rust-lang#5078 (even at expression level now 🎉) Fixes rust-lang#3881 and Fixes rust-lang#4887 (same problem) Fixes rust-lang#3909 Not yet: rust-lang#4140 (test added) All the credit for the fixes goes to `@montrivo.` I only refactored and copy and pasted his code. changelog: rewrite [`use_self`] lint and fix multiple (8) FPs. One to go.
Hey there!
I've just started using Rust, and I really like it. One of the things that makes Rust hard to use is its lack of documentation, which is obviously fine, given that Rust isn't production-ready yet.
I'd like to help change that.
To get started, I've just modified this one little description in the rustdoc. If this works out, and you all like my changes, I'll start working on more docs like this for the rest of core, and maybe the stdlib after that.
What do you think? Any and all feedback welcomed. ❤️