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

[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, DaveA's logic that 
it should be called Unsafe(Mutable)RawBufferPointer is sound but I really don't 
like that name.
  

  
I'll start a thread to pitch removing/renaming Unsafe.
  

  
Karl

  

  
  
>   
> On Sep 7, 2016 at 3:27 pm,  mailto:r...@balancingrock.nl)>  wrote:
>   
>   
>   
>  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 swift-evolution  
> > mailto:swift-evolution@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,wrote:  
> >>   
> >>   
> >>>  On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution  
> >>> 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 (mailto:swift-evolution@swift.org)   
> >   https://lists.swift.org/mailman/listinfo/swift-evolution   
>
>  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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" 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.

Yeah, I didn't realize exactly what "unsafe" meant until quite recently.

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 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" 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,  wrote:
>> 
>> 
>>> 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 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

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

[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, 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,  mailto:atr...@apple.com)>  wrote:
>   
>   
>   
>   
>   
> >   
> > On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution  
> > 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

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

[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 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

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

[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 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 <
> swift-evolution@swift.org> wrote:
> >
> >
> > Hello Swift community,
> >
> > The review of "UnsafeBytes" begins now and runs through September
> > 7th. This late addition to Swift 3 is a follow-up to SE-0107:
> > UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
> > allowing developers to continue working with collections of UInt8 values,
> > but now doing so via a type safe API. The UnsafeBytes API will not
> require
> > direct manipulation of raw pointers or reasoning about binding memory.
> >
> > The proposal is available here:
> >
> > <
> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md
> >
> >
> > Reviews are an important part of the Swift evolution process. All reviews
> > should be sent to the swift-evolution mailing list at
> >
> > 
> >
> > or, if you would like to keep your feedback private, directly to the
> > review manager. When replying, please try to keep the proposal link at
> > the top of the message:
> >
> > Proposal link:
> > 
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> > through constructive criticism and, eventually, determine the direction
> of
> > Swift. When writing your review, here are some questions you might want
> to
> > answer in your review:
> >
> > * What is your evaluation of the proposal?
> > * Is the problem being addressed significant enough to warrant a
> >   change to Swift?
> > * Does this proposal fit well with the feel and direction of Swift?
> > * If you have used other languages or libraries with a similar
> >   feature, how do you feel that this proposal compares to those?
> > * How much effort did you put into your review? A glance, a quick
> >   reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> > 
> >
> > Thank you,
> >
> > -Dave Abrahams
> > Review Manager
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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:
> 
> 
> Hello Swift community,
> 
> The review of "UnsafeBytes" begins now and runs through September
> 7th. This late addition to Swift 3 is a follow-up to SE-0107:
> UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
> allowing developers to continue working with collections of UInt8 values,
> but now doing so via a type safe API. The UnsafeBytes API will not require 
> direct manipulation of raw pointers or reasoning about binding memory.
> 
> The proposal is available here:
> 
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> 
> 
> 
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at
> the top of the message:
> 
> Proposal link:
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
>   change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
>   feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
>   reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> 
> 
> Thank you,
> 
> -Dave Abrahams
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[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 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"?

>  * If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?

Don’t know; maybe, I can’t remember. Better than what we would otherwise have 
for Swift 3, in any case.

>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?

Read the proposal, glossed over the previous discussion. I’ve had similar 
trouble deciphering the new API, so I sympathise with the demonstrations.

> 
> More information about the Swift evolution process is available at
> 
>  
> 
> Thank you,
> 
> -Dave Abrahams
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution