Skip to content

[SE-0302] Clarify inference for non-public structs and enums and frozen public structs and enums #1303

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 2 commits into from
Mar 30, 2021
Merged
Changes from all commits
Commits
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
2 changes: 1 addition & 1 deletion proposals/0302-concurrent-value-and-concurrent-closures.md
Original file line number Diff line number Diff line change
Expand Up @@ -264,7 +264,7 @@ extension MySneakyNSPerson: @unchecked Sendable { }
#### Implicit struct/enum conformance to `Sendable`

Many structs and enums satisfy the requirements of `Sendable`, and having to explicitly write out "`: Sendable`" for every such type can feel like boilerplate.
For non-public, non-frozen structs and enums, the `Sendable` conformance is implicitly provided when conformance checking (described in the previous section) succeeds:
For non-public structs and enums that are also not `@usableFromInline`, and for frozen public structs and enums, the `Sendable` conformance is implicitly provided when conformance checking (described in the previous section) succeeds:
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason the frozen rule doesn't apply to @usableFromInline structs and enums?


```swift
struct MyPerson2 { // Implicitly conforms to Sendable!
Expand Down