[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

[Andrew Trick]

> On Sep 7, 2017, at 11:39 AM, Jordan Rose <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.

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

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

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.

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