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

[Dave Abrahams]

on Tue Jul 05 2016, Andrew Trick <atrick-AT-apple.com> wrote:

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

+1

-- 
Dave