[swift-evolution] Pitch: Improved Swift pointers

[Taylor Swift]

I originally thought that would be too many changes for one proposal but if
y’all think it’s a good idea to deal with those functions too I’m happy to
add it to the proposal!

On Wed, Jul 12, 2017 at 5:07 PM, Michael Ilseman <milseman at apple.com> wrote:

> If you’re considering moving allocate/deallocate to Unsafe*BufferPointer,
> then you probably also want to consider doing the same for initialize,
> deinitialize, and various move functions as well.
>
> 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
> UnsafeMutable*Buffer*Pointer. 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 *Dangerous*Pointers,
> 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>
>
> ~~~
> _______________________________________________
> 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/baa78540/attachment.html>