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

[Xiaodi Wu]

Isn't every use of "Pointer" in the standard library prefixed by "Unsafe"?
If so, we'll want to follow the convention here.
On Wed, Sep 7, 2016 at 07:48 Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:

> >> 1. It points into memory that it does not own. The developer must do
> something to to manage the memory’s lifetime.
>
> Isn't that just a pointer? Is it really necessary to say "unsafe" and
> "pointer"?
>
> And if we did want to make it explicit, perhaps we say "unowned" instead,
> to make it clear how it is unsafe. "RawBufferPointer"/"UnownedRawBufferPointer"
> sound pretty good to me. You can derive some pretty solid expectations from
> those names.
>
> Karl
>
>
> On Sep 6, 2016 at 10:59 pm, <Andrew Trick <atrick at apple.com>> wrote:
>
>
> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160907/38c1d567/attachment.html>