[swift-evolution] Evolving UnsafeMutablePointer.alloc (was Re: [Review] SE-0006 Apply API Guidelines to the Standard Library)

Joe Groff jgroff at apple.com
Sat Jan 23 13:56:26 CST 2016

> On Jan 23, 2016, at 11:38 AM, T.J. Usiyan <griotspeak at gmail.com> wrote:
> I agree that the need to immediately wrap in a BufferPointer is awkward. I've been consistently thrown by the fact that we specify how many items to allocate on the 'single' pointers, though.

Definitely. It would make sense to me if UnsafeMutablePointer's allocation and deallocation APIs worked only for single values, and UnsafeMutableBufferPointer provided similar APIs to allocate and deallocate arrays.

Another thing that might be handy on both types is a `withAllocation { }` function for scoped allocations, which would dealloc for you at block exit (and maybe optionally destroy first).


> On Sat, Jan 23, 2016 at 1:08 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > On Jan 22, 2016, at 11:31 PM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > Hello,
> >
> > I disagree with the following change to UnsafeMutablePointer:
> > -  public static func alloc(num: Int) -> UnsafeMutablePointer<Pointee>
> > +  public init(allocatingCapacity count: Int)
> >
> > This would make it the only constructor in any of OpaquePointer, UnsafePointer, UnsafeMutablePointer and UnsafeReference to have the side-effect of allocating memory. All the others are relatively cheap transformations on pointer values, and get used a lot for typecasting. An allocating constructor would be less locatable among such uses of typecasting-via-constructor. The memory-allocating static method has the merit of sticking out, and pairs nicely with the necessary deallocation call, like the malloc/free pair.
> This all probably deserves a separate discussion from the overall umbrella proposal. Another thing to consider here is whether the logic to allocate an array of values really belongs on UnsafeMutablePointer—it seems like a better fit for UnsafeMutableBufferPointer, whose whole job is to reference an array of objects in memory. Currently, you need to allocate the memory using UnsafeMutablePointer.alloc, then immediately wrap it in a BufferPointer with the same count, which is a bit awkward.
> -Joe
> _______________________________________________
> 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>

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

More information about the swift-evolution mailing list