[swift-evolution] SE-0138 UnsafeBytes

[Drew Crawford]

Proposal link:
 <https://lists.swift.org/mailman/listinfo/swift-evolution>

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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160901/5b95a7c8/attachment.html>