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

[Joe Groff]

> On Jan 22, 2016, at 11:31 PM, Guillaume Lessard via swift-evolution <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