[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 17:09, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Sep 7, 2017, at 2:29 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>>> 
>>> 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.)
> 
> 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.

I don't understand why "realistically, we will always want the runtime to provide malloc_size". Could you explain why?

But then given that, I don't understand why the 'capacity' parameter is necessary. Under what circumstances would it actually be faster than "just" calling malloc_size?

Jordan

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

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