<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 7, 2017, at 13:02, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">UnsafePointer.allocate() is *not*</div><div class=""><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 class=""><br class=""></div><div class="">Even though high-level APIs are specified in terms of this model, they can be implemented via their own fast-paths.<br class=""></div></div></div></blockquote><div><br class=""></div><div>That's all fine; I'll rephrase to say that <i class="">if</i> I allocated with UnsafeMutablePointer.allocate, I'll probably deallocate with Unsafe[Mutable]Pointer.deallocate. They're not independent.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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 class=""><br class=""></div><div class="">We don’t need to claim that manually allocated Swift memory is malloc compatible on every platform that happens to have malloc.</div></div></div></div></blockquote><div><br class=""></div><div>I suspect that we cannot revoke that from existing platforms.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">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><br class=""></div><div>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><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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="">(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 class="">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></div></blockquote><div><br class=""></div><div>That "you" was addressed to Kelvin (Taylor), but if we really think people are mixing malloc/free and UnsafePointer APIs today, we <i class="">should not</i> break that on our existing platforms. It's unfortunate, but we're on Swift 4 already. It is not worth the cost.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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>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><br class=""></div><div>(We also have nothing that prevents you from doing `(ptr+1).deallocate()`, but, well, "unsafe".)</div><br class=""><div class="">Jordan</div></body></html>