[swift-evolution] Pitch: Improved Swift pointers

[Taylor Swift]

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()


On Thu, Jul 13, 2017 at 2:47 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Wed Jul 12 2017, Taylor Swift <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>
>
> 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
> 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/26b683df/attachment.html>