I agree with most of this proposal. Removing the subscript bugs me, but pointer arithmetic currently takes the stride of the type into account, so I don’t necessarily have a problem with that.
I would really appreciate Unsafe*BufferPointer.allocate(count:), and I definitely think the sized deallocators are actively dangerous unless the arguments are used. I fully support their removal. > On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution > <[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 > UnsafeMutableBufferPointer. 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 DangerousPointers, 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>> > > ~~~ > > _______________________________________________ > 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
