Pitch: Add implementation for `withContiguousStorageIfAvailable()` to `Foundation.ContiguousBytes`-conforming sequence types

[Andrew_Trick]

@itaiferber

As someone with 0 authority or input on the matter... I'd say of the three options, it'd probably be easiest to go with (1).

Adding a ContiguousBytes protocol is the most logical way to handle containers that can be viewed as contiguous bytes. But there may be some concern about the runtime overhead associated with adding more conformances to generic types. I'm not sure how valid those concerns still are given the current state of runtime optimization. Nonetheless, it's a significant language change.

@itaiferber

Option (2) was something briefly considered at the time and rejected as unsafe. In general, it's not helpful to expose arbitrary Sequences as sequences of bytes. (Think [String] or Sequence<UnsafeRawPointer> — those aren't useful to traverse as bytes in pretty much any scenario, so you wouldn't want an unconstrained withContiguousBytesIfAvailable exposed on those types.) If it were possible to constrain the extension to Sequence where Element: Trivial (where Trivial is a compiler-controlled marker protocol to indicate POD types) then maybe, but that's not a feature supported by the language right now.

As of Feb 5, 2022, it is reasonably safe to implement Foundation.Data's withContiguousStorageIfAvailable by using withMemoryRebound: SE-0333 Expand usability of withMemoryRebound

@itaiferber

(3) might also be possible, but I have no idea what that work might entail, or whether that's something the language wants to undergo. Someone like @andrew_trick would need to weigh in on this because the subject is out of my wheelhouse.

@CharlesS

is that some kind of warning be added to the documentation for withContiguousStorageIfAvailable on Data and similar constructs like DispatchData , DispatchData.Region , et al., letting the reader know that these will always just return nil . The current Xcode documentation just shows the description inherited from Sequence

This is likely worth filing Feedback for, though I don't believe this is currently possible in the documentation system. Since Data and these other types don't override this method, I don't know if it's possible to attach documentation to the inherited method...

It is now legal to pass a Swift UnsafePointer into a C function taking char *. That solves the problem of calling into (abusive) C APIs that assume char * can alias with anything.

apple/swift-evolution/blob/main/proposals/0324-c-lang-pointer-arg-conversion.md

It is extremely important for Swift programmers, whether they are C experts or not, to realize that casting typed pointers is the wrong way to reinterpret types. There is a safe and convenient way to do this using raw pointers. If they see common examples of code converting typed pointers, rather than using raw pointers, then that is actively misleading. It will lead to more undefined behavior in Swift code as they find ways to force the compiler to cast pointers to other types. Special-casing the semantics of Swift's generic unsafe pointer types based on an element type, which is not always known at compile time, would add a bizarre source of complexity to the language.

Remember that it's common for C code to have undefined behavior related to this. People seldom notice this problem because of limited optimization scope across C libraries.