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

The standard library already makes good use of malloc_size. More to the point, I think “realistically" it needs to be possible to write tools for memory analysis and debugging. I meant “always” in the temporal sense. I don’t think all memory needs this, only memory that is directly under the user’s control.

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

The runtime may need to hash the address or traverse a lookup table to find out which allocation pool the block resides in. Now, that’s only if some platform ditches full malloc compatibility for user allocations, so I’m not sure how realistic it is.

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