[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]

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)
>
>
The problem with subscript notation is we currently get the n argument from
the source argument. So what would really have to be written is

buf[i ..< i + source.count].initialize(from: source)

which is a lot more ugly and redundant. One option could be to decouple the
count parameter from the length of the source buffer, but that opens up the
whole can of worms in which length do we use? What happens if n - i is less
than or longer than source.count? If we enforce the precondition that
source.count
== n - i, then this syntax seems horribly redundant.


> 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.
>

Using Sequences throws out a whole host of assumptions we’ve been taking
advantage of. We can’t check for source.count anymore since that requires
traversing the entire Sequence. And if the performance is so bad relative
to the UnsafePointer API, we have to ask what the purpose of such a buffer
API would even be. The whole purpose of the buffer API was to make it
easier to do things with pointers without having to keep track of buffer
lengths externally. It should be built around the UnsafePointer API, not
the much higher level Sequence API.


>
> 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
>
>
fine with me i guess
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170929/a0113043/attachment.html>