As part of the initial set of proposals for Span, RawSpan, MutableSpan and others, we accepted some functions that reinterpret typed memory as untyped bytes. Some of these have since then had to be revised with an @unsafe annotation. As a result, their names do not reflect the unsafety in typical use (when compiled without -strict-memory-safety). This discussion is about how to solve this discrepancy.
The underlying issue is that after LLVM initializes some storage with a value, it chooses to treat any padding bytes within the storage of the value as uninitialized. This in keeping with its identity as a C compiler, but is neither the only possible choice nor necessarily a desirable behaviour from the compiler for languages that use LLVM but are not C, such as Swift.
We can solve the naming discrepancy in one of two ways:
- Change LLVM's treatment of padding bytes (in Swift mode) so that they do not lead to undefined behaviour, and then remove the
@unsafeannotations for these functions or properties. - Rename these functions and properties to reflect that they are unsafe.
The second option is the simpler one, but doesn't solve the underlying issue. The unsafety comes from a decision of the C language that Swift might not make; is it feasible to make a different decision?
In the meantime, I have prepared a proposal document for renaming (PR), since the standard library is the part of the system I understand best. In short, the @unsafe symbols to be renamed are as follows:
bytes→unsafeBytes(Span,MutableSpan)mutableBytes→unsafeMutableBytes(MutableSpan)append(_:as:)→append(unsafeBytes:as:)(OutputRawSpan)append(repeating:count:as:)→append(repeatingUnsafeBytes:count:as:)(OutputRawSpan)
I'd be glad for this proposal to be put aside in favor of changing LLVM. While the amount of effort is not the same, both have a similar time horizon for completion because of the lengthy deprecation window we must allow for.