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

[SE-0458] Improvements to strict memory safety checking based on the ongoing review #2689

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

DougGregor
Copy link
Member

This pull request improves the proposal in number of ways:

  • Do not require declarations with unsafe types in their signature to be marked @unsafe; it is implied. They may be marked @safe to indicate that they are actually safe.
  • Add unsafe for iteration via the for..in syntax.
  • Add C(++) interoperability section that infers @unsafe for C types that involve pointers.
  • Document the unsafe conformances of the UnsafeBufferPointer family of types to the Collection protocol hierarchy.
  • Restructure detailed design to separate out "sources of unsafety" from "acknowledging unsafety".

…safe

This extra step of requiring @unsafe is mostly busywork. Rather, we
infer @unsafe from unsafe types, and can later suppress false positives
for actually-safe declarations by marking them @safe.
The Detailed Design was becoming a grab-bag of sections, so give it more
structure. First, we describe all of the sources of memory unsafety in
Swift. Then, note the role of the @safe attribute. Finally, describe
all of the ways in which one can acknowledge unsafety.

One drive-by fix here is to document the unsafe conformances of the
`UnsafeBufferPointer` family of types to the `Collection` protocol
hierarchy.
@DougGregor DougGregor requested a review from rjmccall February 12, 2025 07:45

Implementing a protocol requirement that is safe (and not part of an `@unsafe` protocol) within an `@unsafe` declaration introduces unsafety, so it will produce a diagnostic in the strict safety mode:
Swift's `for..in` loops are effectively implemented as syntactic sugar over the `Sequence` and `IteratorProtocol` protocols, where the `for..in` creates a new iterator (with `Sequence.makeIterator()`) and then calls its `next()` operation for each loop iteration. If the conformances to `Sequence` are `IteratorProtocol` is `@unsafe`, the loop will introduce a warning:

Choose a reason for hiding this comment

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

spelling:

... `Sequence` are `IteratorProtocol` is `@unsafe`, the loop will introduce a warning:
               ^~~ and

@@ -740,7 +824,14 @@ We could introduce an optional `message` argument to the `@unsafe` attribute, wh

## Revision history

* **Revision 2 (following first review)**
* **Revision 3 (following second review eextension)**

Choose a reason for hiding this comment

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

Spelling:

**Revision 3 (following second review eextension)**
                                      ^~~~~~~~~~ extension

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.

2 participants