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

[Dave Abrahams]

on Tue Jul 05 2016, Andrew Trick <swift-evolution at swift.org> wrote:

>> On Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> I have a pile of naming quibbles; rather than describe them all in
>> prose (which turned into a mess), I've annotated parts of the "Full
>> UnsafeRawPointer API" section in a gist:
>> <https://gist.github.com/brentdax/8f4ed4decafc1d18c4441092baa13cfe
>>
> <https://gist.github.com/brentdax/8f4ed4decafc1d18c4441092baa13cfe>>.
>
> 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'm not happy with the asymmetry of these forwards/backwards 
>   // pairs.
>   // 
>   // func initialize<T>(from: UnsafePointer<T>, count: Int)
>   //   -> UnsafeMutablePointer<T>
>   // func initializeBackward<T>(from: UnsafePointer<T>, count: Int)
>   //   -> UnsafeMutablePointer<T>
>   func initialize<T>(from: UnsafePointer<T>, forwardToCount: Int)
>     -> UnsafeMutablePointer<T>
>   func initialize<T>(from: UnsafePointer<T>, backwardFromCount: Int)
>     -> UnsafeMutablePointer<T>
>
>   // More detailed thoughts on redesigining `move` methods in the 
>   // email, but for now:
>   // 
>   // func moveInitialize<T>(from: UnsafePointer<T>, count: Int)
>   //   -> UnsafeMutablePointer<T>
>   // func moveInitializeBackward<T>(from: UnsafePointer<T>, count:
> Int)
>   //   -> UnsafeMutablePointer<T>
>   func moveInitialize<T>(from: UnsafePointer<T>, forwardToCount: Int)
>     -> UnsafeMutablePointer<T>
>   func moveInitialize<T>(from: UnsafePointer<T>, backwardFromCount:
> Int)
>     -> UnsafeMutablePointer<T>
>
> Andy
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave