[swift-evolution] [Review] SE-0138 UnsafeBytes

[Andrew Trick]

> On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, but I’m not sure about the “Unsafe” part of “UnsafeBytes” — what is unsafe about getting the byte-representation of a value?
> 
> As I understand it, “Raw” is what we use for “untyped”, so might I suggest “RawBytes"?

It’s annoying, but a strict requirement in Swift that any “unsafe” operation be marked with the word “Unsafe” either at that point or in some enclosing scope. Unsafe broadly refers to various forms of memory unsafety. Unsafe bytes is actually safe with respect to pointer aliasing but it is unsafe because

1. It points into memory that it does not own. The developer must do something to to manage the memory’s lifetime.

2. It does not perform bounds-checking in release mode.

In both those respects, it’s just like UnsafeBufferPointer.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160906/59de7aa0/attachment.html>