[Review] SE-0138 UnsafeBytes

[dabrahams (Dave Abrahams)]

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&gt;

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

  <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

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:
  <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

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

  <https://github.com/apple/swift-evolution/blob/master/process.md&gt;

Thank you,

-Dave Abrahams
Review Manager

[Karl]

* 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

<https://github.com/apple/swift-evolution/blob/master/process.md&gt;

Thank you,

-Dave Abrahams
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[griotspeak (TJ Usiyan)]

+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&gt;

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

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:
<https://lists.swift.org/mailman/listinfo/swift-evolution&gt;

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

<https://github.com/apple/swift-evolution/blob/master/process.md&gt;

Thank you,

-Dave Abrahams
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[xwu (Xiaodi Wu)]

+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
>
> <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
>
> 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:
> <https://lists.swift.org/mailman/listinfo/swift-evolution&gt;
>
> 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
>
> <https://github.com/apple/swift-evolution/blob/master/process.md&gt;
>
> 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

[Andrew_Trick]

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

···

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

[Karl]

  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:atrick@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
  

[David_Sweeris]

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

- Dave Sweeris

···

On Sep 7, 2016, at 05: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.

[xwu (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@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@apple.com>> 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

[Rien]

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 <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, <Andrew Trick> 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

[Karl]

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, <Rien (mailto:rien@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 <swift-evolution@swift.org (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, <Andrew Trick> 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 (mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution