[swift-evolution] Pitch: Improved Swift pointers

[Taylor Swift]

Hi all, i’ve put out a new revision of the proposal which addresses
Michael’s point about dealing with the memorystate APIs along with the
allocation and deallocation API. I didn’t really think about fixing the
memorystate functions originally, but on closer inspection, they are almost
as problematic as the memory allocation API and deserve a closer look.

Here’s a new version of the proposal with revisions
<https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06>


On Wed, Jul 12, 2017 at 6:46 PM, Taylor Swift via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>>
>>
>
> _______________________________________________
> 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/20170713/02207b90/attachment.html>