<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 11:39 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="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">This discussion needs to be grounded by reiterating role of the API. UnsafePointer specifies the memory model without extraneous functionality or convenience.</div><div class=""><br class=""></div><div class="">The UnsafePointer.deallocate() API *is not*:</div><div class=""><br class=""></div><div class="">- a common, expected, or encouraged way to deallocate</div><div class=""><br class=""></div><div class="">- the simplest, safest, or most convenient way to deallocate</div><div class=""><br class=""></div><div class="">- necessarilly the most optimal path for deallocation</div></div></div></div></blockquote><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="">I don't think this is correct. UnsafePointer.deallocate is the API you must use to deallocate memory allocated with UnsafePointer.allocate.</div></div></div></div></blockquote><div><br class=""></div><div>No, all of Swift’s APIs for manual allocation/deallocation need to be compatible. UnsafeBufferPointer is highly preferable to UnsafePointer today. In the future we will have a safe API for manual allocation, still based on the underlying model specified by UnsafePointer.</div><div><br class=""></div><div>UnsafePointer.allocate() is *not*</div><div><br class=""></div>- a common, expected, or encouraged way to allocate<br class=""><br class="">- the simplest, safest, or most convenient way to allocate<br class=""><br class="">- necessarily the most optimal path for allocation</div><div><br class=""></div><div>Even though high-level APIs are specified in terms of this model, they can be implemented via their own fast-paths.<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><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=""><span class="Apple-converted-space"> </span><i class="">My</i>question is whether it's acceptable to break all the people who<span class="Apple-converted-space"> </span><i class="">didn't</i> know this and are using it to deallocate memory allocated with malloc or new on Apple platforms. It sounds like the answer to that is "no, we want to be malloc-compatible", and therefore the 'capacity' parameter isn't currently serving a purpose today. We will<span class="Apple-converted-space"> </span><i class="">always</i> need to check if the memory is actually in the Swift pool before even believing the 'capacity' parameter.</div></div></div></div></blockquote><div><br class=""></div><div>We don’t need to claim that manually allocated Swift memory is malloc compatible on every platform that happens to have malloc. 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><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><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="">(It is definitely true that the<span class="Apple-converted-space"> </span><i class="">intent</i> was for this to be the allocation capacity, and I'm surprised you interpreted it as supporting partial deallocation. But we probably can't fix that at this point.)</div></div></div></div></blockquote><br class=""></div><div>I never misinterpreted the meaning of the API, but apparently multiple people on the evolution list did. Regardless, that is not valid reason for changing the API. It’s only a valid reason for improving documentation and encouraging the use of safer APIs.</div><div><br class=""></div><div>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><br class=""></div><div>Still waiting to hear any arguments that something about that memory model is bad.</div><div><br class=""></div><div>-Andy</div></body></html>