> 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] > <mailto:[email protected]>> wrote: > >> >> >>> On Sep 29, 2017, at 3:48 PM, Taylor Swift <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Sep 29, 2017, at 1:23 PM, Taylor Swift <[email protected] >>>> <mailto:[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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
