[swift-evolution] [late pitch] UnsafeBytes proposal

[Andrew Trick]

> On Aug 13, 2016, at 2:56 AM, Magnus Ahltorp <map at kth.se> wrote:
> 
>> This proposal adds basic usability for working with raw memory without breaking source. The need to provide higher level API for working with raw memory buffers has always been evident, but making improvements in this area depended on first introducing `UnsafeRawPointer`. It was not clear until the final week of source-breaking changes whether SE-0107 would make it into Swift 3. Now that it has, we should use the little remaining time to improve the migration experience and encourage correct use of the memory model by introducing a low-risk additive API.
> 
> As I wrote during the UnsafeRawPointer review, which seems to apply to this proposal as well (forgive me if I have totally misunderstood the proposal):
> 
> When glancing at the examples, they strike me as mostly being marshalling, which in my opinion would be better served by a safe marshalling API followed by unsafe handling of the resulting buffer, and vice versa for unmarshalling. I think it is very important (in the long run) that code that doesn't interact with C directly has safe ways of doing inherently safe operations, and not take the unsafe route just because that is the only API available.
> 
> My question is, how does this API fit into the bigger picture of marshalling, and what are the benefits of using this API instead of marshalling with safe buffers?
> 
> /Magnus

I agree. This proposal has `Unsafe` in its name because it’s not the final solution. It fills an important hole in these use cases—all of which currently interoperate with C—but leaves lifetime management of the memory on the table. It leaves the design of the marshalling feature up to the user intentionally because the primary goal is to migrate existing code. What you’re proposing is more of a new feature and less of a Swift 3 migration usability bug.

-Andy