[swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

[Andrew Trick]

> On Jul 5, 2016, at 10:48 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> I want to call this out separately because it’s not specific to my
>> proposal and changes the existing UnsafePointer API.
>> 
>> Brent’s suggestion is to change `initialize(from:count:)` to
>> `initialize(from:forwardToCount:)` for symmetry with the backward
>> operations. It makes perfect sense to me, and it does a better job of
>> conveying that a sequence of elements will be read out of “from”.
>> 
>> Any objections?
> 
> Well, maybe we ought to think about this again.  I'm not 100% sure we
> should have separate APIs for these; we could compare pointers and
> decide which direction to go in.  The branch should be optimizable-out
> in most situations, right?  And where it couldn't be optimized out,
> you'd currently need to branch manually.
> 
> The concern I have with “backward/forward” is that when you're shifting
> something backwards in memory, you (may) need to proceed forwards, and
> vice-versa.  So these names are easily misinterpreted as having the
> opposite to their actual meaning.
> 
> I suppose there's an argument to be made that CPUs/caches are better at
> going forward than backward, and when the memory regions don't overlap
> you want to go forwards.  But even that is detectable at runtime.  What
> do you think, Andy?


I agree.

The only value in having 2 APIs is that many times the user knows the regions are non-overlapping and may not want a runtime check. In that case forward copying makes more sense.

If the regions may overlap, and if the user somehow knows the relationship between pointers, then the compiler should also. Otherwise, if the pointer comparison is not done in the stdlib, we’re just forcing the user to do it, or allowing them to forget to do it.

Note that there will be no branch in the pure `initialize` case, because the regions are not allowed to overlap anyway. It’s only an issue for moveInitialize and assignInitialize.

How about removing the “BackwardFrom” APIs, adding runtime checks to the forward APIs, and possibly adding non-overlapping “performance” API’s as a separate proposal if needed.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160705/796e5ffa/attachment.html>