[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 6, 2017, at 2:31 PM, Joe Groff <jgroff at apple.com> wrote:
> 
>> 
>> The fact that we’re using malloc and free is already part of the ABI because old libraries need to be able to deallocate memory allocated by newer libraries.
> 
> The compiler doesn't ever generate calls directly to malloc and free, and the runtime entry points we do use already take size and alignment on both allocation and deallocation.

True, we’ve never said that UnsafePointer deallocation is compatible with C, and I we don't currently expose malloc_size functionality in any API AFAIK.

>> Within the standard library we could make use of some new deallocation fast path in the future without worrying about backward deployment.
>> 
>> Outside of the standard library, clients will get the benefits of whatever allocator is available on their deployed platform because we now encourage them to use UnsafeBufferPointer.deallocate(). We can change the implementation inside UnsafeBufferPointer all we want, as long as it’s still malloc-compatible.
>> 
>> I’m sure we’ll want to provide a better allocation/deallocation API in the future for systems programmers based on move-only types. That will already be deployment-limited.
>> 
>> Absolute worst case, we introduce a sized UnsafePointer.deallocate in the future. Any new code outside the stdlib that wants the performance advantage would either need to
>> - trivially wrap deallocation using UnsafeBufferPointer
>> - create a trivial UnsafePointer.deallocate thunk under an availability flag
> 
> Since we already have sized deallocate, why would we take it away? If the name is misleading, we can change the name.


I don't think leaving it as an optional argument is worthwhile, as I explained above. Deallocation capacity is either required or we drop it completely. If we keep it, then `allocatedCapacity` is the right name.

The reason for taking it away, beside being misleading, is that it exposes another level of unsafety.

My thinking has been that this is not the allocation fast path of the future, and the stdlib itself could track the size of unsafely-allocated blocks if it ever used a different underlying allocator.

Now I realize this isn't really about fast/slow deallocation paths. Removing `capacity` or even making it optional forces all future Swift implementations to provide malloc_size functionality for any piece of memory that is compatible with the Unsafe API.

I'm actually ok with that, because I think it's generally desirable for application memory to reside in either in malloc-compatible blocks or fixed size pools. i.e. I think malloc_size is something the platform needs. However, you seem to think this would be too restrictive in the future. How is this a known problem for C and what's your confidence level it will be a problem for Swift?

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