When using *Unsafe* in Swift, Swift becomes as "safe" as C(++). Research shows that about 70% of the security vulnerabilities are related to memory unsafety.
Swift and SwiftNIO try to offer programmers fast and safe APIs which should mostly make the use of *Unsafe* constructs unnecessary. If that is not the case, we appreciate feature requests to add API allowing to use safe APIs to the respective projects.
Modifications:
Add a bullet that says *Unsafe* only if absolutely necessary.
Concrete wording update (in "Conventions and Style"):
Does not use *Unsafe* unless interfacing with C
Exceptions to uses of *Unsafe* constructs are tolerated if appropriately documented why they are absolutely necessary
When *Unsafe* is used in this manner, it would be appreciated for feature requests to be made for Swift or SwiftNIO in order to make the use of the *Unsafe* construct obsolete.
It is helpful to have as many APIs as possible that allow using safe constructions without unduly sacrificing performance. Many such abstractions exist in Swift today, and more are being built all the time. We should build for that future, and try to avoid excessive use of Unsafe APIs.
We should also as a community construct design guidelines around unsafe APIs. One thing I have found helpful is to try to constrain the scope of unsafe APIs: rather than designing functions that pass unsafe pointers through multiple layers of function calls with unclear rules, it is frequently better to design APIs that expose the unsafe parts of the code for as short a period of time as possible. These APIs allow easy auditing of code for correctness, helping make it easier to find bugs.
With Swift on the server getting more and more users, I think we should always strife to make the standards & packages approved by the SSWG as safe as possible, both for experienced and beginners.