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

Taylor Swift kelvin13ma at gmail.com
Sun Sep 3 22:38:40 CDT 2017


what was the reasoning for making raw at: offset in strides and not bytes?

> On Sep 3, 2017, at 10:22 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>>> On Sep 3, 2017, at 8:05 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> 
>>> If we use byte offset, then the at parameter in UnsafeMutableRawPointer should be removed, since pointer arithmetic can be used instead (just like with UnsafeMutablePointer).
>> 
>> I agree that it seems quite sensible to remove the ‘at’ parameter altogether from the UMRP method.
> 
> No code in tree or on github is using the `at` argument. I think it can be removed. A fixit should still be possible.
> 
>>> Not convinced moving the at: argument to come before the as: argument is worth it in terms of source breakage.
>> 
>> Since much of this proposal involves shuffling and relabeling arguments, I’d argue it’s better to break slight more source in one go for the optimal API than to break slightly less for a slightly less optimal API, no? (This is assuming there is agreement that ‘at:as:’ is less prone to misinterpretation than ‘as:at:’.)
> 
> 
> To be clear, we’re just talking about UnsafeMutableRawBufferPointer.initializeMemory now, so this is purely additive.
> I think the label needs to be `atByteOffset`, and placing it before `as` makes a lot of sense because it no longer depends on the type’s stride. 
> 
> -Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170903/6adc5da2/attachment.html>


More information about the swift-evolution mailing list