> On Jul 13, 2017, at 6:16 PM, Taylor Swift via swift-evolution > <swift-evolution@swift.org> wrote: > > I am not very familiar with the inner workings of the standard library, > however I maintain a few libraries which make extensive use of Swift > pointers, such as https://github.com/kelvin13/maxpng > <https://github.com/kelvin13/maxpng> which makes extensive use of > Unsafe_____Pointers. I also write a lot of code that interfaces with C APIs > like Cairo and OpenGL. Most of the ideas in the original proposal came from > me dealing with the current Swift pointer APIs in my own code. For example I > find myself writing this bit of code > > let buffer = UnsafeMutableBufferPointer<UInt8>(start: > UnsafeMutablePointer<UInt8>.allocate(capacity: byteCount), count: byteCount) > defer > { > buffer.baseAddress?.deallocate(capacity: buffer.count) > } > > far more than I would like to. While this proposal doesn’t solve every > problem with Swift pointers — for example, we need a UMBP initializer that > takes an immutable buffer pointer before we are really able to write a lot of > examples more concisely, it takes us a great deal closer to being able to > write things like > > UnsafeMutablePointer(mutating: > self.zero_line.baseAddress!).deallocate(capacity: self.zero_line.count) > > as > > UnsafeMutableBufferPointer(mutating: self.zero_line).deallocate()
You should not need to do this at all. A pointer does not need to be mutable to deallocate the memory. That’s a bug in the UnsafePointer API. -Andy > > On Thu, Jul 13, 2017 at 2:47 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > on Wed Jul 12 2017, Taylor Swift <swift-evolution@swift.org > <mailto:swift-evolution@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 > > <https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06>> > > I have no problem with this direction in principle; it sounds like a > good idea. However, before affirming any particular design I would like > to see the results of any such proposal applied to a fairly large body > of code that uses Unsafe[XXX]Pointer today in diverse ways (such as the > Swift standard library itself), to demonstrate that it does in fact > improve the code in practice. > > Cheers, > > -- > -Dave > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
