>> 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 (mailto:atr...@apple.com)> wrote:
>
>
>
>
>
> >
> > On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution
> > <swift-evolution@swift.org (mailto:swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
