okay, well until someone can come up with a subscript syntax that does what we need it to do, I’m inclined to view at:from: in the function parameter list as the clearest and most straightforward syntax. We shouldn’t use the square brackets for the sake of using square brackets.
On Sat, Sep 30, 2017 at 6:51 PM, Dave Abrahams <[email protected]> wrote: > I don't think I made any arguments that could be viewed as pointing out a > problem with the slice approach, unless you take as given the idea that the > slice approach should mean something novel and unprecedented. I don't see > the whole/part implication that you see in the two notations, even though I > understand why you want to read it that way, in particular *because* of > the precedent I cited. > > On Sep 30, 2017, at 4:23 PM, Taylor Swift <[email protected]> wrote: > > yeah, which is why I think the at:from: system is better than any > subscript alternative. I know everyone wants to use the square brackets but > it just doesn’t work very well for exactly the reasons you mentioned. > > On Sat, Sep 30, 2017 at 6:07 PM, Dave Abrahams <[email protected]> > wrote: > >> >> >> On Sep 29, 2017, at 4:03 PM, Taylor Swift <[email protected]> wrote: >> >> >> >> On Sep 29, 2017, at 5:56 PM, Dave Abrahams <[email protected]> wrote: >> >> >> >> On Sep 29, 2017, at 3:48 PM, Taylor Swift <[email protected]> wrote: >> >> >> >> On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <[email protected]> wrote: >> >>> >>> >>> On Sep 29, 2017, at 1:23 PM, Taylor Swift <[email protected]> wrote: >>> >>> Instead of >>>> >>>> buf.intialize(at: i, from: source) >>>> >>>> We want to force a more obvious idiom: >>>> >>>> buf[i..<n].intialize(from: source) >>>> >>>> >>> The problem with subscript notation is we currently get the n argument >>> from the source argument. So what would really have to be written is >>> >>> buf[i ..< i + source.count].initialize(from: source) >>> >>> which is a lot more ugly and redundant. One option could be to decouple >>> the count parameter from the length of the source buffer, but that opens up >>> the whole can of worms in which length do we use? What happens if n - i is >>> less than or longer than source.count? If we enforce the precondition >>> that source.count == n - i, then this syntax seems horribly redundant. >>> >>> >>> Sorry, a better analogy would have been: >>> >>> buf[i...].intialize(from: source) >>> >>> Whether you specify the slice’s end point depends on whether you want to >>> completely initialize that slice or whether you’re just filling up as much >>> of the buffer as you can. It also depends on whether `source` is also a >>> buffer (of known size) or some arbitrary Sequence. >>> >>> Otherwise, point taken. >>> >>> -Andy >>> >> >> After thinking about this more, one-sided ranges might provide just the >> expressivity we need. What if: >> >> buf[offset...].initialize(from: source) // initializes source.count >> elements from source starting from offset >> >> buf[offset ..< endIndex].initialize(from: source) // initializes up to >> source.count elements from source starting from offset >> >> >> The one sided one does not give a full initialization guarantee. The two >> sided one guarantees the entire segment is initialized. >> >> >> In every other context, x[i...] is equivalent to x[i..<x.endIndex] >> >> I don't think breaking that precedent is a good idea. >> >> For move operations, the one sided one will fully deinitialize the source >> buffer while the two sided one will only deinitialize endIndex - offset >> elements. >> >> >> — >> -Dave >> >> >> well since people want to use subscript notation so much we need some way >> of expressing case 1. writing both bounds in the subscript seems to imply a >> full initialization (and thus partial movement) guarantee. >> >> >> Yes, I understood your reasoning. Do you understand why I still don't >> want to proceed in that direction? >> >> — >> -Dave >> >> >> >> >> >> > > — > -Dave > > > > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
