Skip to content

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

Merged
merged 12 commits into from
Aug 25, 2021

Conversation

amartini51
Copy link
Member

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

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>.
@amartini51 amartini51 requested review from ktoso and DougGregor August 9, 2021 22:06
Copy link
Contributor

@ktoso ktoso left a 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!

@@ -122,14 +128,19 @@ extension Task {
}
}

/// Attempt to cancel the task.
/// Indicate that the task should stop.
Copy link
Contributor

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.

Copy link
Member Author

@amartini51 amartini51 Aug 10, 2021

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

?

Copy link
Member Author

@amartini51 amartini51 Aug 17, 2021

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.

@amartini51 amartini51 changed the base branch from release/5.5 to release/5.5-08092021 August 10, 2021 22:23
@amartini51
Copy link
Member Author

@swift-ci Please test

@ktoso
Copy link
Contributor

ktoso commented Aug 17, 2021

Thanks Alex, nice edits!

I pondered a bit about the cancel docs, let me know what you think but the PR is LGTM 👍

@ghost ghost mentioned this pull request Aug 17, 2021
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>.
@amartini51 amartini51 marked this pull request as ready for review August 19, 2021 06:59
@amartini51 amartini51 requested a review from a team as a code owner August 19, 2021 06:59
@amartini51
Copy link
Member Author

@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.
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

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 '^- *///\|^+ *///'
Comment on lines 391 to 392
/// ◊TR: Why do we have two implementations of this method?
/// ◊TR: What's the difference between them?
Copy link
Member Author

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?

Comment on lines 374 to 376
/// 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?
Copy link
Member Author

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?

Comment on lines 670 to 672
/// 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?
Copy link
Member Author

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?

Comment on lines 687 to 688
/// ◊TR: Why do we have two implementations of this method?
/// ◊TR: What's the difference between them?
Copy link
Member Author

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?

Comment on lines 19 to 20
/// ◊TR: Why do we have both sleep(_:) and sleep(nanoseconds:) -- what's the difference between them?
/// ◊TR: It looks like only sleep(nanoseconds:) throws.
Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Member Author

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?

@amartini51
Copy link
Member Author

@swift-ci Please test.

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 9b456df

@amartini51
Copy link
Member Author

@swift-ci Please test macOS platform.

@amartini51 amartini51 requested a review from a team August 25, 2021 00:15
@najacque najacque merged commit b9dde85 into swiftlang:release/5.5-08092021 Aug 25, 2021
amartini51 added a commit that referenced this pull request Aug 25, 2021
@amartini51 amartini51 deleted the docs_task_81184794 branch December 8, 2021 17:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants