<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><div id="bloop_customfont" style="margin: 0px;"><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;">Proposal link:</span><br class="" style="font-family: 'helvetica Neue', helvetica; font-size: 14px;"><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;"> <</span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" style="font-family: 'helvetica Neue', helvetica; font-size: 14px;">https://lists.swift.org/mailman/listinfo/swift-evolution</a><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;">></span></div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">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;"><br></div><div id="bloop_customfont" style="margin: 0px;">I definitely agree that the problem is significant enough to warrant a last-minute change.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">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;"><br></div><div id="bloop_customfont" style="margin: 0px;">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;"><br></div><div id="bloop_customfont" style="margin: 0px;">Drew</div></div> <br> <div id="bloop_sign_1472774292422429184" class="bloop_sign"></div> <br><p class="airmail_on">On September 1, 2016 at 5:19:02 PM, Andrew Trick via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div>
<title></title>
<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>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>