> On Jul 5, 2016, at 11:27 AM, Xiaodi Wu <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > >> On Jul 5, 2016, at 11:05 AM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
