[swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Jordan Rose]

> On Sep 7, 2017, at 13:02, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Sep 7, 2017, at 11:39 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>>> This discussion needs to be grounded by reiterating role of the API. UnsafePointer specifies the memory model without extraneous functionality or convenience.
>>> 
>>> The UnsafePointer.deallocate() API *is not*:
>>> 
>>> - a common, expected, or encouraged way to deallocate
>>> 
>>> - the simplest, safest, or most convenient way to deallocate
>>> 
>>> - necessarilly the most optimal path for deallocation
>> 
>> I don't think this is correct. UnsafePointer.deallocate is the API you must use to deallocate memory allocated with UnsafePointer.allocate.
> 
> 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.
> 
> UnsafePointer.allocate() is *not*
> 
> - a common, expected, or encouraged way to allocate
> 
> - the simplest, safest, or most convenient way to allocate
> 
> - necessarily the most optimal path for allocation
> 
> Even though high-level APIs are specified in terms of this model, they can be implemented via their own fast-paths.

That's all fine; I'll rephrase to say that if I allocated with UnsafeMutablePointer.allocate, I'll probably deallocate with Unsafe[Mutable]Pointer.deallocate. They're not independent.


> 
>>  Myquestion is whether it's acceptable to break all the people who didn't 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 always need to check if the memory is actually in the Swift pool before even believing the 'capacity' parameter.
> 
> We don’t need to claim that manually allocated Swift memory is malloc compatible on every platform that happens to have malloc.

I suspect that we cannot revoke that from existing platforms.

> 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.

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.)


> 
>> (It is definitely true that the intent 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.)
> 
> 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.

That "you" was addressed to Kelvin (Taylor), but if we really think people are mixing malloc/free and UnsafePointer APIs today, we should not break that on our existing platforms. It's unfortunate, but we're on Swift 4 already. It is not worth the cost.


> If our memory model states that the runtime tracks capacity of manually allocated blocks, then the deallocation capacity should be optional to reflect that.
> 
> Still waiting to hear any arguments that something about that memory model is bad.

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.

(We also have nothing that prevents you from doing `(ptr+1).deallocate()`, but, well, "unsafe".)

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170907/3df1e3dc/attachment.html>