> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution > <swift-evolution@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 <kelvin1...@gmail.com > <mailto:kelvin1...@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 <kelvin1...@gmail.com > <mailto:kelvin1...@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. -Andy
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
