[swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"
dabrahams at apple.com
Tue Jul 5 16:07:13 CDT 2016
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
> 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.
More information about the swift-evolution