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

[Taylor Swift]

we agreed to deprecate the strided at:? Note that
UnsafeMutableRawBufferPointer would still need a byteOffset: argument. I’m
also still not comfortable with duplicating functionality for the sake of
having two names

On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick <atrick at apple.com> wrote:

> I think we’ve agreed to a few minor updates to this proposal. Since there
> hasn’t been any other feedback on the thread it may be worth posting an
> amended proposal so we all know what we’ve agreed on.
>
> -Andy
>
> On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution <
> swift-evolution at swift.org> 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
> _______________________________________________
> 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/20170905/e1254827/attachment.html>