Skip to content

Remove the mention of ~Sendable from the concurrency chapter. #373

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.

Sign up for GitHub

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+9 −6
Open

Remove the mention of ~Sendable from the concurrency chapter. #373

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5eebedb
Remove the mention of `~Sendable` from the concurrency chapter.
hborla Jun 10, 2025
e6b3be3
Fix syntax in code listing
amartini51 Jun 16, 2025
c4e7904
Xref the comparison of unavailable and ~P syntax
amartini51 Jun 16, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions TSPL.docc/LanguageGuide/Concurrency.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1568,12 +1568,15 @@ struct TemperatureReading {
-->

To explicitly mark a type as not being sendable,
write `~Sendable` after the type:
write an unavailable conformance to `Sendable`:
Copy link
Member

Choose a reason for hiding this comment

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

Is it correct to describe using the availability annotation as an unavailable conformance? If there's not a ~Sendable, then I might suggest using a phrasing like:

"mark the Sendable conformance as unavailable."

Copy link
Member Author

Choose a reason for hiding this comment

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

I've always used the term "unavailable conformance" for this. What I don't like about "mark the Sendable conformance as unavailable" is that it doesn't tell you that you need to actually add the conformance and then mark it as unavailable. I personally prefer the existing wording. Curious what @amartini51 thinks.

Copy link
Member

Choose a reason for hiding this comment

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

I prefer the term "unavailable conformance", which I think is more descriptive. The extension adds conformance to the Sendable protocol, and the @available attribute marks the conformance as unavailable.

For comparison/precedent, the Protocols chapter describes the same syntax in its example as:

Another way to suppress implicit conformance is with an extension that you mark as unavailable:

And it uses the wording "suppress an implicit conformance" for the ~Protocol syntax.


```swift
struct FileDescriptor: ~Sendable {
struct FileDescriptor {
let rawValue: Int
}

@available(*, unavailable)
extension FileDescriptor: Sendable {}
```

<!--
Expand All @@ -1584,9 +1587,9 @@ See also this PR that adds Sendable conformance to FileDescriptor:
https://github.com/apple/swift-system/pull/112
-->

For more information about
suppressing an implicit conformance to a protocol,
see <doc:Protocols#Implicit-Conformance-to-a-Protocol>.
You can also use an unavailable conformance
to suppress implicit conformance to a protocol,
as discussed in <doc:Protocols#Implicit-Conformance-to-a-Protocol>.

<!--
LEFTOVER OUTLINE BITS
Expand Down
2 changes: 1 addition & 1 deletion TSPL.docc/LanguageGuide/Protocols.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1480,7 +1480,7 @@ is with an extension that you mark as unavailable:

```swift
@available(*, unavailable)
extension FileDescriptor Sendable { }
extension FileDescriptor: Sendable { }
```

<!--
Expand Down