[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

[Taylor Swift]

On Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

> > Currently, memory is deallocated by an instance method on
> UnsafeMutablePointer, deallocate(count:). Like much of the Swift pointer
> API, performing this operation on a buffer pointer requires extracting
> baseAddress! and count. It is very common for the allocation code above to
> be immediately followed by:
> >
> > defer
> >
> > {
> >     buffer.
> > baseAddress?.deallocate(capacity: buffer.count
> > )
> > }
> >
> > This method is extremely problematic because nearly all users, on first
> seeing the signature of deallocate(capacity:), will naturally conclude from
> the capacity label that deallocate(capacity:) is equivalent to some kind of
> realloc()that can only shrink the buffer. However this is not the actual
> behavior — deallocate(capacity:) actually ignores the capacity argument and
> just calls free() on self. The current API is not only awkward and
> suboptimal, it is misleading. You can write perfectly legal Swift code that
> shouldn’t segfault, but still can, for example
> >
> > var ptr = UnsafeMutablePointer<UInt8>.allocate(capacity: 1000000
> > )
> > ptr.
> > initialize(to: 13, count: 1000000
> > )
> > ptr.
> > deallocate(capacity: 500000) // deallocate the second half of the memory
> block
> > ptr[0] // segmentation fault
> > where the first 500000 addresses should still be valid if the
> documentation is to be read literally.
>
> The fact that the Swift runtime currently uses malloc/free is an
> implementation detail. Tracking deallocation size is a very useful
> optimization for better allocator backends, and C++ underwent an ABI break
> to make it so that sized delete can be supported. Maybe we can change the
> name to `deallocate(allocatedCapacity:)` to make it clear that it isn't
> resizing the memory, and/or make the capacity argument optional so that you
> can pay for the overhead of the allocator deriving the size if it's
> inconvenient for the calling code to carry the size around, but we
> shouldn't remove the functionality altogether.
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

The idea is to get the house in order by removing all parameters from
deallocate(), since that’s what it really does right now. Then, in the
future, if Swift gets a more sophisticated allocator backend, a new method
like deallocate(capacity:) or reallocate(toCapacity:) could be added
without conflicting with the currently named deallocate(capacity:).
However, using the function signature to pretend that it does something it
can’t actually do right now is extremely dangerous.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170906/24d3ec23/attachment.html>