Skip to content
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

Try to improve the documentation of filter() and filter_map(). #75949

Merged
merged 1 commit into from
Sep 6, 2020

Conversation

vext01
Copy link
Contributor

@vext01 vext01 commented Aug 26, 2020

I believe the documentation is currently a little misleading.

For example, in the docs for filter():

If the closure returns false, it will try again, and call the closure on
the next element, seeing if it passes the test.

This kind of implies that if the closure returns true then we don't "try
again" and no further elements are considered. In actuality that's not the
case, every element is tried regardless of what happened with the previous
element.

This change tries to clarify that by removing the uses of "try again"
altogether.

@rust-highfive
Copy link
Collaborator

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 26, 2020
@vext01
Copy link
Contributor Author

vext01 commented Aug 26, 2020

I've just noticed that I wrapped my lines longer than before. Let me know if that's an issue and I'll fix it.

@Dylan-DPC-zz
Copy link

r? @steveklabnik

@steveklabnik
Copy link
Member

I've just noticed that I wrapped my lines longer than before. Let me know if that's an issue and I'll fix it.

What column are they wrapped to? Standard library, IIRC, uses 80.

@vext01
Copy link
Contributor Author

vext01 commented Aug 28, 2020

Re-wrapped to 80 and made the docs for filter_map() yet more concise.

What do you think?

@vext01
Copy link
Contributor Author

vext01 commented Aug 28, 2020

It occurs to me that it might be better to say returned iterator instead of filtered result? Thoughts?

Copy link
Member

@steveklabnik steveklabnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks good, but yeah, I also hear you about the "returned iterator". Hmmm...

@vext01
Copy link
Contributor Author

vext01 commented Sep 1, 2020

Having thought a little more, I prefer "returned iterator". Fix pushed.

OK to squash?

@jyn514 jyn514 added A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-iterators Area: Iterators labels Sep 3, 2020
@bors
Copy link
Contributor

bors commented Sep 3, 2020

☔ The latest upstream changes (presumably #76265) made this pull request unmergeable. Please resolve the merge conflicts.

@vext01
Copy link
Contributor Author

vext01 commented Sep 3, 2020

Rebased to resolve merge conflict. Another change updated the links which I had removed anyway.

@hbina
Copy link
Contributor

hbina commented Sep 3, 2020

Why not something like "The returned iterator will only contain elements that returns true when applied to the predicate". Short and no double negatives with "false" and "not"

@vext01
Copy link
Contributor Author

vext01 commented Sep 3, 2020

I'd go for a slight tweak on that:

The returned iterator will only contain the elements for which the closure returns true.

(And we've already said that each element will be passed to the closure)

@jyn514
Copy link
Member

jyn514 commented Sep 3, 2020

You removed some links also that need to be added back:

error: unresolved link to `filter`
   --> library/core/src/iter/traits/iterator.rs:743:44
    |
743 |     /// Here's the same example, but with [`filter`] and [`map`]:
    |                                            ^^^^^^^^ unresolved link
    |
    = note: `-D broken-intra-doc-links` implied by `-D warnings`
    = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`

error: unresolved link to `map`
   --> library/core/src/iter/traits/iterator.rs:743:59
    |
743 |     /// Here's the same example, but with [`filter`] and [`map`]:
    |                                                           ^^^^^ unresolved link
    |
    = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`

I still consider #75949 (comment) a blocking concern though.

@vext01
Copy link
Contributor Author

vext01 commented Sep 4, 2020

I've had a shot at addressing comments.

There's a curious merge conflict (for a path I've not touched), but we can look at that later.

Are we getting any closer?

@jyn514
Copy link
Member

jyn514 commented Sep 4, 2020

There's a curious merge conflict (for a path I've not touched), but we can look at that later.

You updated submodules, I'm not quite sure how to fix it. Maybe git reset master src/{doc,edition-guide,reference,rust-by-example} src/tools/{cargo,miri,rust-analyzer}?

Comment on lines 720 to 722
/// Given an element the closure must return `Some(value)` or `None`. The
/// returned iterator will only yield a value when the closure returns
/// `Some`. The values inside the `Some`s are yielded.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a little verbose, but I'm not sure how better to word it. It seems like it's saying the same thing 3 times sort of.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I spent quite some time trying to get these three sentences down to 2 (or even better one), but failed.

It's hard to explain concisely that it is not the element that is returned, but the innards of the Some that is returned.

I'm open to suggestions, but also I'd like to move forward. You can always tweak this in a later PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would something like this be any better?

The returned iterator yields only the values for which the supplied closure returns Some(value).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooh, I like that!

library/core/src/iter/traits/iterator.rs Show resolved Hide resolved
@jyn514
Copy link
Member

jyn514 commented Sep 5, 2020

r=me without the submodule updates. Not sure how exactly to fix those ... maybe something like this?

git checkout filter-docs
git reset fd001558c8f077da2e9e645c6667881b48524e72
git add library/core/src/iter/traits/iterator.rs
git commit -m "Address comments"
git push -f

@vext01
Copy link
Contributor Author

vext01 commented Sep 5, 2020

@jyn514 I think we raced. I made a suggestion in the above thread at the same time as it was marked resolved.

@vext01
Copy link
Contributor Author

vext01 commented Sep 5, 2020

I think this should be good.

Assuming all is well, can I squash?

@rust-log-analyzer
Copy link
Collaborator

The job mingw-check of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
Initialized empty Git repository in /home/runner/work/rust/rust/.git/
##[command]git remote add origin https://github.com/rust-lang/rust
##[command]git config gc.auto 0
##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/75949/merge:refs/remotes/pull/75949/merge

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

@jyn514
Copy link
Member

jyn514 commented Sep 5, 2020

Looks good to me but you still need to undo the submodule changes: #75949 (comment)

I believe the documentation is currently a little misleading.

For example, in the docs for `filter()`:

> If the closure returns `false`, it will try again, and call the closure on
> the next element, seeing if it passes the test.

This kind of implies that if the closure returns true then we *don't* "try
again" and no further elements are considered. In actuality that's not the
case, every element is tried regardless of what happened with the previous
element.

This change tries to clarify that by removing the uses of "try again"
altogether.
@vext01
Copy link
Contributor Author

vext01 commented Sep 5, 2020

Ugh. I thought I had removed those.

I think this is the desired result (with a squash also).

@jyn514
Copy link
Member

jyn514 commented Sep 5, 2020

@bors r+ rollup

Thanks for the PR! (and for persisting through the trouble with submodules)

@bors
Copy link
Contributor

bors commented Sep 5, 2020

📌 Commit 8af85fa has been approved by jyn514

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 5, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 5, 2020
Try to improve the documentation of `filter()` and `filter_map()`.

I believe the documentation is currently a little misleading.

For example, in the docs for `filter()`:

> If the closure returns `false`, it will try again, and call the closure on
> the next element, seeing if it passes the test.

This kind of implies that if the closure returns true then we *don't* "try
again" and no further elements are considered. In actuality that's not the
case, every element is tried regardless of what happened with the previous
element.

This change tries to clarify that by removing the uses of "try again"
altogether.
@bors
Copy link
Contributor

bors commented Sep 6, 2020

⌛ Testing commit 8af85fa with merge 642ebd19e1bccb1179d6acee8af7e56f8920b242...

@bors
Copy link
Contributor

bors commented Sep 6, 2020

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 6, 2020
@rust-log-analyzer
Copy link
Collaborator

Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
##[group]Run exit 1
exit 1
shell: /bin/bash --noprofile --norc -e -o pipefail {0}
##[endgroup]
##[error]Process completed with exit code 1.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

@jyn514
Copy link
Member

jyn514 commented Sep 6, 2020

@bors retry

network error:

curl: (56) SSLRead() return error -9806
clang+llvm-10.0.0-x86_64-apple-darwin/include/clang/AST/ExprObjC.h: Lzma library error:  No progress is possible
tar: Error exit delayed from previous errors.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 6, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 6, 2020
Try to improve the documentation of `filter()` and `filter_map()`.

I believe the documentation is currently a little misleading.

For example, in the docs for `filter()`:

> If the closure returns `false`, it will try again, and call the closure on
> the next element, seeing if it passes the test.

This kind of implies that if the closure returns true then we *don't* "try
again" and no further elements are considered. In actuality that's not the
case, every element is tried regardless of what happened with the previous
element.

This change tries to clarify that by removing the uses of "try again"
altogether.
@bors
Copy link
Contributor

bors commented Sep 6, 2020

⌛ Testing commit 8af85fa with merge 5d74e88...

@bors
Copy link
Contributor

bors commented Sep 6, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: jyn514
Pushing 5d74e88 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 6, 2020
@bors bors merged commit 5d74e88 into rust-lang:master Sep 6, 2020
@rustbot rustbot added this to the 1.48.0 milestone Sep 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: documentation for any part of the project, including the compiler, standard library, and tools A-iterators Area: Iterators merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants