<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 1 sept. 2016 à 17:37:47, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The proposal is available here:<br class=""><br class=""> <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md</a>><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 1, 2016, at 4:59 PM, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>> wrote:</div><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px;" class=""><div id="bloop_customfont" style="margin: 0px;" class="">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.</div><div id="bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="margin: 0px;" class="">I definitely agree that the problem is significant enough to warrant a last-minute change.</div><div id="bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="margin: 0px;" class="">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.</div><div id="bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="margin: 0px;" class="">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.</div><div id="bloop_customfont" style="margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="margin: 0px;" class="">Drew</div></div></div></blockquote><div class=""><br class=""></div><div class="">In my current implementation:</div><a href="https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb" class="">https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb</a></div><div class=""><br class=""></div><div class="">The bounds checks in `copyBytes(from:)` are release mode preconditions.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I don’t think makes a lot of sense as generic Collection though. Alternatively, we just have an UnsafeBoundsCheckedBytes wrapper.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><br class=""></div></div><div class="">-Andy<br class=""><blockquote type="cite" class=""><div class=""><p class="airmail_on" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On September 1, 2016 at 5:19:02 PM, Andrew Trick via swift-evolution (<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>) wrote:</p><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""></div><div class=""><div class="">I’m resending this for Review Manager Dave A. because the announce list is dropping his messages...</div><div class=""><br class=""></div>Hello Swift community,<br class=""><br class="">The review of "UnsafeBytes" begins now and runs through September<br class="">7th. This late addition to Swift 3 is a follow-up to SE-0107:<br class="">UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,<br class="">allowing developers to continue working with collections of UInt8 values,<br class="">but now doing so via a type safe API. The UnsafeBytes API will not require <br class="">direct manipulation of raw pointers or reasoning about binding memory.<br class=""><br class="">The proposal is available here:<br class=""><br class=""> <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md</a>><br class=""><br class="">Reviews are an important part of the Swift evolution process. All reviews<br class="">should be sent to the swift-evolution mailing list at<br class=""><br class=""> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class=""><br class="">or, if you would like to keep your feedback private, directly to the<br class="">review manager. When replying, please try to keep the proposal link at<br class="">the top of the message:<br class=""><br class="">Proposal link:<br class=""> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class=""><br class="">What goes into a review?<br class=""><br class="">The goal of the review process is to improve the proposal under review<br class="">through constructive criticism and, eventually, determine the direction of<br class="">Swift. When writing your review, here are some questions you might want to<br class="">answer in your review:<br class=""><br class=""> * What is your evaluation of the proposal?<br class=""> * Is the problem being addressed significant enough to warrant a<br class=""> change to Swift?<br class=""> * Does this proposal fit well with the feel and direction of Swift?<br class=""> * If you have used other languages or libraries with a similar<br class=""> feature, how do you feel that this proposal compares to those?<br class=""> * How much effort did you put into your review? A glance, a quick<br class=""> reading, or an in-depth study?<br class=""><br class="">More information about the Swift evolution process is available at<br class=""><br class=""> <<a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a>><br class=""><br class="">Thank you,<br class=""><br class="">-Dave Abrahams<br class="">Review Manager _______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></span></blockquote></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>