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 <kelvin1...@gmail.com> 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 <dabrah...@apple.com > <mailto:dabrah...@apple.com>> wrote: > > >> On Sep 29, 2017, at 4:03 PM, Taylor Swift <kelvin1...@gmail.com >> <mailto:kelvin1...@gmail.com>> wrote: >> >> >> >> On Sep 29, 2017, at 5:56 PM, Dave Abrahams <dabrah...@apple.com >> <mailto:dabrah...@apple.com>> wrote: >> >>> >>> >>>> On Sep 29, 2017, at 3:48 PM, Taylor Swift <kelvin1...@gmail.com >>>> <mailto:kelvin1...@gmail.com>> wrote: >>>> >>>> >>>> >>>> On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <atr...@apple.com >>>> <mailto:atr...@apple.com>> wrote: >>>> >>>> >>>>> On Sep 29, 2017, at 1:23 PM, Taylor Swift <kelvin1...@gmail.com >>>>> <mailto:kelvin1...@gmail.com>> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
