[swift-evolution] Pitch: Improved Swift pointers

[Taylor Swift]

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)
>
> 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 <
> 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
>>
>
> _______________________________________________
> 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/20170714/d353a871/attachment.html>