[swift-evolution] SE-0138 UnsafeBytes

[Rien]

Probably the biggest argument is that it will make the migration more palatable.
Most (??) apps today use some form of communication, and proving a better pointer solution is a big selling point.
I know that my migration would have been faster and more efficient…

Rien.

> On 02 Sep 2016, at 16:45, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm +1 on the proposal. Not a lot to say about it; I don't expect the community to have a passionate argument either.
> 
> Félix
> 
>> Le 1 sept. 2016 à 17:37:47, Andrew Trick via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> The proposal is available here:
>> 
>>  <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md>
>> 
>>> On Sep 1, 2016, at 4:59 PM, Drew Crawford <drew at sealedabstract.com> wrote:
>>> I'm possibly one of the larger users of raw byte stuff in Swift as I maintain an entire client/server network protocol stack in Swift userspace, similar in spirit to one of the examples drawn out a lot longer.  Grepping my code produces over 200 individual uses of unsafe byte accesses.
>>> 
>>> I definitely agree that the problem is significant enough to warrant a last-minute change.
>>> 
>>> To a first approximation I agree with all the implementation choices.  The naming, the choice of UInt8, length tracking, and debug-bounds checking are all correct IMO.  We have been using something similar for a long time internally [have you been reading my code? :-) ] so I can speak from experience that the basic plan here is sound.
>>> 
>>> One thing I would like to see is an (opt-in) release-mode-bounds-check.  Networking is a core use case for this feature, but when you are reading from a socket, production is where you need a guard against out-of-bounds UB the most.  If we can't solve it for Swift 3, affected users can write a wrapper to implement the boundscheck, but I think we should at very least take it up again for Swift 4.
>>> 
>>> Drew
>> 
>> In my current implementation:
>> https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb
>> 
>> The bounds checks in `copyBytes(from:)` are release mode preconditions.
>> 
>> The bounds checks for `subscript`, `load(as:)`, and `storeBytes(of:as:)` are debug only because it’s likely they occur in some loop that could be covered by a single bounds check. By extension, the sequence iterator is only bounds checked in debug mode.
>> 
>> One possibility would be different names for the bounds checked forms of those methods: getByte(atOffset:), setByte(atOffset:), load(fromCheckedOffset:as:), storeBytes(of:toCheckedOffset:as:). Along with some kind of bounds checked Iterator.
>> 
>> I don’t think makes a lot of sense as generic Collection though. Alternatively, we just have an UnsafeBoundsCheckedBytes wrapper.
>> 
>> This would a good thing to experiment with in your project. We may be able to follow-up with a Swift 4 proposal. The important thing now is to determine whether the proposed Swift 3 design will make that wrapper difficult in any way.
>> 
>> -Andy
>>> On September 1, 2016 at 5:19:02 PM, Andrew Trick via swift-evolution (swift-evolution at swift.org) wrote:
>>> 
>>>> I’m resending this for Review Manager Dave A. because the announce list is dropping his messages...
>>>> 
>>>> 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>
>>>> 
>>>> 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>
>>>> 
>>>> 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>
>>>> 
>>>> Thank you,
>>>> 
>>>> -Dave Abrahams
>>>> Review Manager _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution