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 >> <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
