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

[Taylor Swift]

The implementation is complete and building successfully:
https://github.com/apple/swift/pull/12200

On Sat, Sep 30, 2017 at 2:56 PM, Taylor Swift via swift-evolution <
swift-evolution at swift.org> wrote:

> https://github.com/apple/swift-evolution/pull/750
> https://github.com/apple/swift/pull/12200
>
> On Sat, Sep 30, 2017 at 2:15 AM, Taylor Swift <kelvin13ma at gmail.com>
> wrote:
>
>>
>>
>> On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick <atrick at apple.com> wrote:
>>
>>>
>>> On Sep 6, 2017, at 10:15 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>>>
>>> okay so I think so far what’s been agreed on is
>>>
>>> *1*. rename “Bytes” to “Memory” in the raw pointer API. Note: this
>>> brings the `copyBytes<C>(from:)` collection method into the scope of
>>> this proposal
>>>
>>> *2*. change raw offsets to be in terms of bytes, not typed strides.
>>> This argument will be called `atByteOffset:` and will only appear in
>>> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in
>>> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>>>
>>>
>>> *3*. move UnsafeMutableBufferPointer’s `at:` arguments to the front of
>>> the parameter list. mostly cause any pointer arithmetic happens in the
>>> front so structurally we want to mirror that.
>>>
>>> *4*. add dual (to:) single element initializers and assigners to
>>> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s
>>> apparently not useful there. `UnsafeMutableRawPointer.initi
>>> alizeMemory<T>(as:repeating:count:)` still loses its default count to
>>> prevent confusion with its buffer variant.
>>>
>>> *5*. memory deallocation on buffer pointers is clearly documented to
>>> only be defined behavior when the buffer matches a whole heap block.
>>>
>>>
>>> Kelvin,
>>>
>>> Attempting to limit the scope of this proposal backfired. I was hoping
>>> to avoid discussing changes to the slice API, instead providing basic
>>> functionality within the buffer API itself. However, Dave Abrahams has
>>> argued that once the slice API is extended, the positional arguments are
>>> extraneous and less clear.
>>>
>>> Instead of
>>>
>>>   buf.intialize(at: i, from: source)
>>>
>>> We want to force a more obvious idiom:
>>>
>>>   buf[i..<n].intialize(from: source)
>>>
>>> I think this is a reasonable argument and convinced myself that it's
>>> possible to extend the slice API. I'm also convinced now that we don't need
>>> overloads to handle an UnsafeBufferPointer source, instead we can provide a
>>> single generic entry point on both UnsafeMutableBufferPointer and its
>>> slice, optimized within the implementation:
>>>
>>>  `initialize<S : Sequence>(from: S) -> (S.Iterator, Index)
>>>
>>> We can always drop down to the UnsafePointer API to get back to a direct
>>> unsafe implementation as a temporary workaround for performance issues.
>>>
>>> Let's set aside for now whether we support full or partial
>>> initialization/assignment, how to handle moveInitialize, and whether we
>>> need to return the Iterator/Index. This is going to require another
>>> iteration on swift-evolution, which *we should discuss in a separate
>>> thread*.
>>>
>>> At this point, I suggest removing the controversial aspects of SE-0184
>>> so that we can put the other changes behind us and focus future discussion
>>> around a smaller follow-up proposal.
>>>
>>> Here I've summarized the changes that I think could be accepted as-is:
>>> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e
>>>
>>> If you amend SE-0184 accordingly and file a new PR, I think it can be
>>> quickly approved.
>>>
>>> -Andy
>>>
>>>
>> Part one of SE-0184 is here as SE-0184 A
>> <https://github.com/kelvin13/swift-evolution/blob/improved-pointers/proposals/0184a-unsafe-pointers-part-1.md>
>> I’ll implement it tomorrow and then make the PR
>>
>
>
> _______________________________________________
> 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/20171004/631a2995/attachment.html>