The proposal is available here: <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md>>
> On Sep 1, 2016, at 4:59 PM, Drew Crawford <d...@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 <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@swift.org <mailto: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 >> >> <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 >> <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 >> <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 >> <https://github.com/apple/swift-evolution/blob/master/process.md>> >> >> Thank you, >> >> -Dave Abrahams >> Review Manager _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
