<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 3, 2016, at 3:36 PM, Drew Crawford &lt;<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><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;"><br class="Apple-interchange-newline">On September 2, 2016 at 2:36:43 AM, Andrew Trick (<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>) wrote:</p><div 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;" class=""><blockquote type="cite" class="clean_bq"><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;" class="">After thinking about this for a moment, I like the approach of extending UnsafeBytes with release-mode bounds checked versions of subscript, load, and storeBytes.</span></blockquote></div><p 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;" class="">I agree with this, I think it's mostly a question of naming and defaults. &nbsp;My concern here is letting a swift developer accidentally write heartbleed, which we can't actually prevent, but we can make it harder.</p><p 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;" class="">IMO&nbsp;</p><p 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;" class="">1. &nbsp;There should be clear consistency in the checked-ness of the API surface. &nbsp;Agree that checked iterator makes no sense, but I think the most important thing is to avoid creating a job interview trivia game where `set` is checked but `store` is unchecked, spot the bug in this function.</p><p 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;" class="">2. &nbsp;For consistency with UnsafeBufferPointer it may make the most sense to just ship unchecked or ship an opt-in checked wrapper. &nbsp;I believe however that the existing precedent is all wrong on this point, and I'd like to see us revisit this question across both interfaces in Swift 4, but I don't want to lay out a whole case here that should be its own thread.</p></div></blockquote></div>I generally agree with what you said. I think the vague plan is later in Swift 4 to ship a bounds-checked variant of both UnsafeBufferPointer and UnsafeBytes (or &nbsp;UnsafeRawBufferPointer if you prefer).<div class=""><br class=""></div><div class="">I don’t want to eliminate the debug-mode checks though. I did try to make it clear in the comments that bounds-checking only applied to debug mode, so developers should not accidentally become too reliant on them.</div><div class=""><br class=""></div><div class="">So, the only question is whether the UnsafeBytes.copyBytes() API should have debug or release-mode checks. My decision to keep the stronger checks here was probabilistic—it seems unlikely to be a performance issue but likely to catch most buffer overruns. But I agree that it is inconsistent, especially if we plan to introduce a release bounds-checked variant later. We don’t want developers to begin relying on that check. I’m leaning toward dropping it down to a debug-mode check.</div><div class=""><br class=""></div><div class="">-Andy</div></body></html>