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

[Andrew Trick]

> On Jul 5, 2016, at 11:27 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> I'm not sure about that. "Initialize backward from x, count y" is unambiguous as to how initialization starts and iterates (the first argument), and it is clear that `count` is an end condition dissociated from anything to do with how initialization starts and iterates.
> 
> By contrast, "Initialize from x, backward from y" associates the direction of movement with y instead of x. Thus, y becomes the start condition (the end condition being implicitly "to zero"), thus raising the question of what position x is in relative to the count y.

"Initialize backward from x" literally tells me that ‘x’ is the starting point, which is incorrect. Honestly, users will need to check the doc comments which are very precise.

-Andy

> On Tue, Jul 5, 2016 at 11:10 Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
> 
>> On Jul 5, 2016, at 11:05 AM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> I don't mind `initialize(from:forwardToCount:)`, but I do have trouble with Brent's suggestion of `initialize(from:backwardFromCount:)`. It adds ambiguity as to whether the pointer in the first argument points to the 0th element or the (count - 1)th element from which initializing is proceeding backward, a problem that does not exist with the currently proposed version `initializeBackward(from:count:)`. I don't find the symmetry wins compelling enough to overcome that additional ambiguity.
> 
> That’s a good point, but I think both forms are equally ambiguous.
> 
> -Andy

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