[swift-evolution] Pitch: Improved Swift pointers

[Harlan Haskins]

I agree with most of this proposal. Removing the subscript bugs me, but pointer arithmetic currently takes the stride of the type into account, so I don’t necessarily have a problem with that.

I would really appreciate Unsafe*BufferPointer.allocate(count:), and I definitely think the sized deallocators are actively dangerous unless the arguments are used. I fully support their removal.

> On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi all, I’ve written up a proposal to modify the unsafe pointer API for greater consistency, safety, and ease of use.
> 
> ~~~
> 
> Swift currently offers two sets of pointer types — singular pointers such as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutableBufferPointer. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement Collection conformance, while singular pointers do not.
> 
> However, some aspects of the pointer design contradict these implied roles. It is possible to allocate an arbitrary number of instances from a type method on a singular pointer, but not from a buffer pointer. The result of such an operation returns a singular pointer, even though a buffer pointer would be more appropriate to capture the information about the number of instances allocated. It’s possible to subscript into a singular pointer, even though they are not real Collections. Some parts of the current design turn UnsafePointers into downright DangerousPointers, leading users to believe that they have allocated or freed memory when in fact, they have not.
> 
> This proposal seeks to iron out these inconsistencies, and offer a more convenient, more sensible, and less bug-prone API for Swift pointers.
> 
> <https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06 <https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06>>
> 
> ~~~
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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