[swift-evolution] SE-184 Improved Pointers

Andrew Trick atrick at apple.com
Fri Aug 18 18:55:55 CDT 2017

> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution <swift-evolution at swift.org> wrote:
> Implementation is here: https://github.com/apple/swift/pull/11464 <https://github.com/apple/swift/pull/11464>
> On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> wrote:
> I’ve revised the proposal based on what I learned from trying to implement these changes. I think it’s worth tacking the existing methods that take Sequences at the same time as this actually makes the design a bit simpler.
> <https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c <https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c>>
> The previous version <https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907> of this document ignored the generic initialization methods on UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer, leaving them to be overhauled at a later date, in a separate proposal. Instead, this version of the proposal leverages those existing methods to inform a more compact API design which has less surface area, and is more future-proof since it obviates the need to design and add another (redundant) set of protocol-oriented pointer APIs later.
> On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift <kelvin13ma at gmail.com <mailto:kelvin13ma at gmail.com>> wrote:
> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you!
> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md <https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md>>

Would you mind adding a deallocate method to (nonmutable) UnsafePointer/UnsafeBufferPointer to take care of
[SR-3309](https://bugs.swift.org/browse/SR-3309 <https://bugs.swift.org/browse/SR-3309>)?

There’s simply nothing in the memory model that requires mutable memory for deallocation.

It fits right in with this proposal and hardly seems worth a separate one.


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

More information about the swift-evolution mailing list