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 < [email protected]> 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 <[email protected]>> wrote: > > > On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
