On Fri, Jul 14, 2017 at 12:29 AM, Andrew Trick <[email protected]> wrote:
> > On Jul 13, 2017, at 6:16 PM, Taylor Swift via swift-evolution < > [email protected]> 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 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 > > I think this falls under “convenience methods that would be really nice to have but should probably go in a separate proposal”. > > On Thu, Jul 13, 2017 at 2:47 PM, Dave Abrahams via swift-evolution < > [email protected]> wrote: > >> >> on Wed Jul 12 2017, Taylor Swift <[email protected]> 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> >> >> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
