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