[swift-evolution] Pitch: Improved Swift pointers
kelvin13ma at gmail.com
Fri Jul 14 00:35:08 CDT 2017
On Fri, Jul 14, 2017 at 12:29 AM, Andrew Trick <atrick at apple.com> wrote:
> 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 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)
> 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.
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 <
> 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
>> > as UnsafeMutablePointer, and vector (buffer) pointers such as
>> > *Buffer*Pointer. This implies a natural separation of tasks the two
>> > 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
>> > 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
>> > such an operation returns a singular pointer, even though a buffer
>> > would be more appropriate to capture the information about the *number*
>> > instances allocated. It’s possible to subscript into a singular pointer,
>> > even though they are not real Collections. Some parts of the current
>> > 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution