SE-0458: Opt-in Strict Memory Safety Checking

Evolution Proposal Reviews
33

As the proposal author, Doug has asked to make a handful of revisions to SE-0458:

  • Using a local variable of unsafe type as an argument of an explicitly @safe API will no longer be treated as unsafe. For example, if buf is an UnsafeBufferPointer<Int>, it will be possible to write buf.count or buf.endIndex without writing the unsafe operator.
  • Types that contain stored properties or enum payloads of unsafe type will no longer default to being considered safe and must be explicitly annotated as @safe or @unsafe.
  • There is a new Alternatives Considered section on prohibiting unsafe conformances and overrides.
  • There is a new Future Directions section on handling unsafe code in macro expansions.

You can read the PR to see the exact set of changes.

I have applied these changes to the proposal document, and I am extending the review until February 11th, 2025.

John McCall
Review Manager

5 Likes