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 <dabrahams@apple.com> 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 <kelvin13ma@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 <dabrahams@apple.com> > wrote:
On Sep 29, 2017, at 4:03 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:
On Sep 29, 2017, at 5:56 PM, Dave Abrahams <dabrahams@apple.com> wrote:
On Sep 29, 2017, at 3:48 PM, Taylor Swift <kelvin13ma@gmail.com> wrote:
On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick <atrick@apple.com> wrote:
On Sep 29, 2017, at 1:23 PM, Taylor Swift <kelvin13ma@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 isbuf[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 offsetbuf[offset ..< endIndex].initialize(from: source) // initializes up to
source.count elements from source starting from offsetThe 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.—
-Davewell 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