Hi all,
The discussion here in this review thread has been very helpful, thank you! I've gone ahead and made another round of revisions to the proposal based on the feedback here, which I've gathered together in a pull request. The specific changes are:
- Do not require declarations with unsafe types in their signature to be marked
@unsafe; it is implied. They may be marked@safeto indicate that they are actually safe. - Add
unsafefor iteration via thefor..insyntax. - Add C(++) interoperability section that infers
@unsafefor C types that involve pointers. - Document the unsafe conformances of the
UnsafeBufferPointerfamily of types to theCollectionprotocol hierarchy.
The document itself has gotten a bit unwieldy, so I also did some restructuring for clarity that doesn't change the actual meaning beyond the above. Instead of a large, flat list of topics in Detailed Design, I've split out two subsections: one for sources of unsafety (@unsafe, the language constructs, @unsafe conformances, the standard library declarations that are marked @unsafe, etc.) and another for acknowledging unsafety (unsafe expression, unsafe for the for..in loop, using @safe and @unsafe to acknowledge safety by propagating it further, etc.). If you've already read it, it's not worth reading again for these changes, but it should make this document a better reference going forward.
Cheers,
Doug