[swift-evolution] Pitch: Improved Swift pointers
kelvin13ma at gmail.com
Thu Jul 13 19:41:52 CDT 2017
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
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>
>> 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution