-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Clean up doc comments for task APIs. #38815
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
Clean up doc comments for task APIs. #38815
Conversation
Use only plain English words in abstracts, no symbol names, per reference writing guidelines. Use title case for headings. Use spelling from Apple Style Guide for 'canceled' and 'canceling'. Track TaskGroup async(...) renaming to addTask(...) in code examples. Fill in the -Parameters: markup for methods and initializers that take parameters, starting the sentence with an upper-case letter. Add links to TSPL for conceptual discussion, re-using the prose from elsewhere in the standard library reference for the cross reference. Restore some prose from fe288c2 in places where cleanup and revision work to doc comments got overwritten by API revision. Restore some prose that was in the discussion of Task.Handle that was deleted in commit 27bf2c9. Reduce the number of places where we talk about cooperative cancellation in detail, and let the individual properties and methods lean on the longer discussion in the overview for Task. Remove mention of error propagation from getResult(), which doesn't throw and therefor can't propagate errors thrown by a task. Remove mention of what the add(...) methods do if the operation throws an error from the non-throwing TaskGroup type, since the operation there can't ever be throwing. Remove -Returns: markup from properties and from methods that don't return a value. Stored and computed properties *have* a value, which is documented by their abstract and discussion sections; functions and methods *return* a value. Remove cross references when they refer to type that's part of the declaration. The rendered documentation already provides an affordance to navigate to a type in that context. Fixes <rdar://81184794>.
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.
A few minor things, looks good -- thank you!
stdlib/public/Concurrency/Task.swift
Outdated
@@ -122,14 +128,19 @@ extension Task { | |||
} | |||
} | |||
|
|||
/// Attempt to cancel the task. | |||
/// Indicate that the task should stop. |
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 don't think "stop" is a safe word to use here, it makes one thing we actively "stop tasks from executing" which isn't the case. It's a bit repetetive but I think we must stick to cancellation wording here, and not introduce new verbs like stopping etc.
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.
Maybe we can brainstorm verbs? The guidelines for writing reference strongly discourage repeating the API symbol name in the abstract (this first line of docs), to avoid the problem of saying things like:
doTheThing()
Does the thing.
Where the abstract just repeats in English, using most of the same words, what the symbol name already told you.
I'm particularly hesitant about "attempts" because that sounds to me like the language/framework's implementation of cancellation is only a best effort. We will always tell the task to cancel — whether or not cancellation happens depends on whether that task listens for cancellation, and how that task responds to cancellation.
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 see what you mean with it then just repeating the API name... I don't have any other great ideas though :-( Stops makes me pretty worried, we never "stop" anything, the task may continue to run forever for all we know hmm...
You're right on "attempts" that'd be potentially misleading.
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.
Maybe...
Puts the task in cancelled state, for which it may or may not check and act upon.
?
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.
Thanks. How about "Requests that the task should cancel its work."? Or "Indicates that the task should stop running."? I don't like "cancel its work" very much, because it uses "cancel" in a different sort of meaning than we already have in the surrounding reference when we talk about canceling a task.
The fact that a task might ignore cancellation doesn't need to be in the abstract; we discuss it in the paragraphs below.
@swift-ci Please test |
Thanks Alex, nice edits! I pondered a bit about the cancel docs, let me know what you think but the PR is LGTM 👍 |
Changes from <rdar://81715064>
This includes: - Edits to /// comments for non-public symbols - Edits to // comments (not documentation) - Edits to warnings and other strings in code
Fixes <rdar://82053644>.
@swift-ci Please test. |
// unconditionally add the cancellation record to the task. | ||
// if the task was already cancelled, it will be executed right away. | ||
// Unconditionally add the cancellation record to the task. | ||
// If the task was already canceled, it executes immediately. |
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.
"If the task was already canceled, it executes immediately."
This makes it sound like "the task executes immediately", which I presume is not the case for a task that was already canceled.
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.
Nice catch - this is a //
comment, not part of the documentation, so should not be changed by these edits. I did a visual check for these for commit 6a79590; and I'll run my usual grep
script to check for others now.
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.
Reverted in a0e58c6. @ktoso or @DougGregor do you want to work with @tbkka to improve this internal comment as needed?
Thanks, @tbkka! Confirmed this was the only one by running: git diff github/release/5.5-08092021...HEAD \ | grep '^+\|^-' \ | grep -v '^+++\|^---' \ | grep -v '^- *///\|^+ *///'
/// ◊TR: Why do we have two implementations of this method? | ||
/// ◊TR: What's the difference between them? |
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.
@ktoso or @DougGregor can you comment?
/// There are no restrictions on where you can call this method. | ||
/// Code inside a child task or even another task can cancel a group. | ||
/// ◊TR: Is this rewrite too strong? |
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.
@ktoso or @DougGregor can you comment?
/// There are no restrictions on where you can call this method. | ||
/// Code inside a child task or even another task can cancel a group. | ||
/// ◊TR: Is this rewrite too strong? |
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.
@ktoso or @DougGregor can you comment?
/// ◊TR: Why do we have two implementations of this method? | ||
/// ◊TR: What's the difference between them? |
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.
@ktoso or @DougGregor can you comment?
/// ◊TR: Why do we have both sleep(_:) and sleep(nanoseconds:) -- what's the difference between them? | ||
/// ◊TR: It looks like only sleep(nanoseconds:) throws. |
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.
@ktoso or @DougGregor can you comment?
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 thought we were going to deprecate sleep(_:)
so that we could later bring it back when we had a legitimate Duration
type. If the argument is just a raw number, then denoting the units as sleep(nanoseconds:)
is much clearer.
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 sounds right to me, but I don't see an @availability
annotation on sleep(_:)
that marks it as deprecated here or on the release branch. It sounds like there should be one?
@swift-ci Please test. |
Build failed |
@swift-ci Please test macOS platform. |
Use only plain English words in abstracts, no symbol names, per
reference writing guidelines.
Use title case for headings.
Use spelling from Apple Style Guide for 'canceled' and 'canceling'.
Track TaskGroup async(...) renaming to addTask(...) in code examples.
Fill in the -Parameters: markup for methods and initializers that take
parameters, starting the sentence with an upper-case letter.
Add links to TSPL for conceptual discussion, re-using the prose from
elsewhere in the standard library reference for the cross reference.
Restore some prose from fe288c2 in
places where cleanup and revision work to doc comments got overwritten
by API revision.
Restore some prose that was in the discussion of Task.Handle that was
deleted in commit 27bf2c9.
Reduce the number of places where we talk about cooperative cancellation
in detail, and let the individual properties and methods lean on the
longer discussion in the overview for Task.
Remove mention of error propagation from getResult(), which doesn't
throw and therefor can't propagate errors thrown by a task.
Remove mention of what the add(...) methods do if the operation throws
an error from the non-throwing TaskGroup type, since the operation there
can't ever be throwing.
Remove -Returns: markup from properties and from methods that don't
return a value. Stored and computed properties have a value, which is
documented by their abstract and discussion sections; functions and
methods return a value.
Remove cross references when they refer to type that's part of the
declaration. The rendered documentation already provides an affordance
to navigate to a type in that context.
Fixes rdar://81184794