<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 7, 2017, at 2:29 PM, 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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class="Apple-interchange-newline">We do want the Swift memory model to be consistent with the reality that on most platforms, we need the runtime to track block size.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't know where this comes from. If you don't need to be malloc-compatible, you don't strictly "need" this information. (It would break tools like 'leaks', though.)</div></div></div></blockquote><div><br class=""></div><div>There are two distinct but related issues (1) malloc compatibility (2) malloc/free like functionality. I know developers sometimes expect or want #2. Realistically, we will always want the runtime to provide malloc_size, even if it’s not super fast, so we’re not giving up anything long term by providing #2. The fact the #1 is also a likely goal on major platforms just reinforces that position.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">If our memory model states that the runtime tracks capacity of manually allocated blocks, then the deallocation capacity should be optional to reflect that.</div><div class=""><br class=""></div><div class="">Still waiting to hear any arguments that something about that memory model is bad.</div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I don't see an advantage to having the parameter if we're going to promise that it's always present. It is additional complexity for very little win in a generic interface. If someone wants to write a special allocation entry point that actually makes use of this, they can do so, but it shouldn't live on UnsafePointer.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">(We also have nothing that prevents you from doing `(ptr+1).deallocate()`, but, well, "unsafe".)</div></div></blockquote></div><br class=""><div class="">I also don’t see any usability advantage in providing the extra argument for anyone directly using UnsafePointer, which is why I initially objected to Joe Groff’s request. Then I realized I care less about usability and potential confusion than I care that UnsafePointer API can be viewed is a specification of the Swift's basic memory management functionality. We want to communicate that data structures doing manual allocation/deallocation should provide the allocated capacity during deallocation if it is available. The runtime could make good use of that. In particular, I want UnsafeBufferPointer’s deallocate() to be able to call UnsafePointer.deallocate(allocatedCapacity: buffer.count), rather than implementing it in terms of Builtins.</div><div class=""><br class=""></div><div class="">Incidentally, FWIW, I think compiled code should continue to be required to pass the capacity to the runtime during deallocation. That way, any changes in the runtime implementation of deallocation, particularly extra address checks, are isolated to the standard library.</div><div class=""><br class=""></div><div class="">-Andy</div></body></html>