[swift-evolution] Pitch: Improved Swift pointers

[Andrew Trick]

> On Jul 13, 2017, at 6:16 PM, Taylor Swift via swift-evolution <swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> on Wed Jul 12 2017, Taylor Swift <swift-evolution at swift.org <mailto: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.
> >
> > <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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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