<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=""><div class="">Responding to this on the swift-evolution thread...</div><div class=""><a href="https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsafebytepointer.md" class="">https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsafebytepointer.md</a></div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">On May 12, 2016, at 9:27 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Some concerns with UnsafeBytePointer:</div><div class=""><br class=""></div><div class="">- I was concerned about having a store() to go with load(). It’s just deinitialize + initialize with a count of 1, but that’s easily the common case when you do need to write to something. That said, I’m not sure which people are more likely to mess up: using initialize and forgetting to deinitialize before, or using store when there wasn’t anything there before.</div></div></blockquote><div class=""><br class=""></div><div class="">store() is definitely a common case, but it is subtly broken if the user doesn't realize that the overwritten value must be exactly the same type. The problem is that this API is advertised as supporting type punning. The only way to make it safe as advertised is to force users to deinitialize<T>() + initialize<U>. I think this needs to be clearly explained in the API comments.</div><div class=""><br class=""></div><div class="">+ ///</div><div class="">+ /// - Note: The converse of loading a value, storing a value `T` into</div><div class="">+ /// initialized memory requires the user to know the previously initialized</div><div class="">+ /// value's type. Full 'store' semantics can be achieved with:</div><div class="">+ /// `deinitialize(PreviousType)`</div><div class="">+ /// `initialize(NewType, with: value)`</div><div class="">+ /// If the previosly initialized type cannot reference any managed objects,</div><div class="">+ /// then the `deinitialize` call can be skipped.</div><div class=""> public func load<T>(_ : T.Type) -> T {</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">- I am concerned about eliminating the distinction between mutable and immutable memory. That is, I think we’ll want the Mutable variant to be a separate type.</div></div></blockquote><div class=""><br class=""></div><div class="">Yes. I haven't gotten feedback yet on that, or on importing 'void*' as UnsafeBytePointer. If the feeling on both is positive, then I think it's worth ammending my proposal at this point to include UnsafeMutableBytePointer.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">- Is there a good way to do a mass copy or move <i class="">from</i> an UnsafeBytePointer?</div></div></blockquote><div class=""><br class=""></div><div class=""><div class=""><div class="">I didn’t add ‘move’ from UnsafeBytePointer for the same reason that I didn’t add ‘store’.</div><div class=""><br class=""></div><div class="">I could add the following functions to Unsafe[Mutable]Pointer though for completeness:</div><div class=""><br class=""></div><div class="">- initialize(from: UnsafeBytePointer, count)</div><div class="">- assign(from: UnsafeBytePointer, count)</div><div class=""><br class=""></div><div class="">I could also add a mass move from UnsafePointer *to* UnsafeBytePointer.</div><div class=""><br class=""></div><div class=""> func moveInitializeFrom<T>(_ source: UnsafePointer<T>, count: Int) {</div><div class=""> func moveInitializeBackwardFrom<T>(_ source: UnsafePointer<T>, count: Int) {</div></div><div class=""><br class=""></div><div class="">-Andy</div></div></body></html>