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

2016-09-07 Thread Karl Wagner via swift-evolution
Yeah it definitely should be it's own proposal. It's just that add we add new Unsafe types, the naming is becoming ridiculous and doesn't clearly express the information developer's need to know when using the types. It's always been a bit iffy, but as I look at the proposal,

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

2016-09-07 Thread David Sweeris via swift-evolution
> On Sep 7, 2016, at 05:48, Karl Wagner via swift-evolution > 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"

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

2016-09-07 Thread Rien via swift-evolution
As much as I would like to get rid of the “Unsafe” prefix, for this change it should imo be considered “out of scope”. Since it is used for the other pointers, it should be used here also. Maybe a separate proposal to get rid of “Unsafe”? Rien > On 07 Sep 2016, at 14:48, Karl Wagner via

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

2016-09-07 Thread Xiaodi Wu via swift-evolution
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@swift.org> wrote: > >> 1. It points into memory that it does not own. The developer must do >

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

2016-09-07 Thread Karl Wagner via swift-evolution
>> 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,

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

2016-09-06 Thread Andrew Trick via swift-evolution
> On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution > 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

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

2016-09-03 Thread Xiaodi Wu via swift-evolution
+1 as well. I would love to have Data.withUnsafeBytes use this type, and I agree that UnsafeBytes and Data have orthogonal and not overlapping use cases. On Sat, Sep 3, 2016 at 08:59 gs. via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > I think that 'Unsafe' is fine because the

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

2016-09-03 Thread gs. via swift-evolution
+1 I think that 'Unsafe' is fine because the mutable variant is definitely unsafe. I have some audio related code that would benefit greatly from this addition so I am all for it. TJ > On Sep 1, 2016, at 12:10, Dave Abrahams via swift-evolution > wrote: > > >

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

2016-09-02 Thread Karl via swift-evolution
> > * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a >change to Swift? Yup > * 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