[swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

Andrew Trick atrick at apple.com
Tue Sep 5 20:57:39 CDT 2017


> On Sep 5, 2017, at 6:28 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
> 
>> 
>> UMRP (raw pointer):
>> --- func initializeMemory<T>(as:at:(=0)count:(1)to:)
>> +++ func initializeMemory<T>(as:repeating:count:) // remove default count 
>> 
>> still extremely suspicious of this but i’m willing to compromise. also there should be an `initializeMemory<T>(at:to:)` to match the typed methods
>> 
>> Do you mean initializeMemory<T>(as:to:)?
> 
> I don’t think it’s necessary since raw buffers are not normally used to hold a single typed element. We don’t need symmetry between raw and typed pointers and I wouldn’t want to add an API that will never be used. So, I would be ok with it only if there’s some use case that I’m overlooking.
> 
> The only case i can think of is initializing a buffer header but then again i rarely use raw pointers so i’m not sure how much this feature would be used. However, this function is already <https://developer.apple.com/documentation/swift/unsafemutablerawpointer/2427589-initializememory> in the API (with a default count of 1 and offset of 0) so there’s that.

Yeah, but you’re deprecating the old API entry point anyway. The `at` argument was never used AFAICT. I doubt code is using the default `count` and it seems like a fixit could handle it.

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


More information about the swift-evolution mailing list