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

[T.J. Usiyan]

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.

On Sat, Jan 23, 2016 at 1:08 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > 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
> _______________________________________________
> 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/20160123/76d7011e/attachment.html>