<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;"><br></div><p class="airmail_on">On September 2, 2016 at 2:36:43 AM, Andrew Trick (<a href="mailto:atrick@apple.com">atrick@apple.com</a>) wrote:</p><div><blockquote type="cite" class="clean_bq"><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;">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>I agree with this, I think it's mostly a question of naming and defaults. 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>IMO </p><p>1. There should be clear consistency in the checked-ness of the API surface. 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>2. For consistency with UnsafeBufferPointer it may make the most sense to just ship unchecked or ship an opt-in checked wrapper. 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></div></body></html>