> On Oct 11, 2017, at 3:42 PM, Ben Cohen <ben_co...@apple.com> wrote:
>
>
>
>> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> there is no way to allow one-sided subscripting, but disallow two-sided
>> subscripting for the memory API
>
> One-sided subscripting is just shorthand for “from here to the end” (or from
> the start to/through here). If a one-sided subscript is just shorthand for a
> two-sided subscript there cannot be a circumstance where one is allowed but
> not the other. This kind of rule should be consistent throughout the library.
You are entirely correct which is why i’m not comfortable with this syntax.
>
> If a “from:” argument, similarly, means “write from here up to the end” (and
> no further, it’s reasonable to assume, if we’re talking about collections)
> then x.foo(from: i) is similar to saying x[i…].foo(), which in turn is
> similar to saying x[5..<x.endIndex].foo()
>
from: in the buffer pointer API refers to the source buffer which contains a
`count` property. it’s analogous to the count: argument in the plain pointer
API.
> Do you feel like a “from:” argument avoids implying there is a specific end
> point to the operation? That is, it might not get as far as x.endIndex if it
> runs out of stuff to write. Whereas x[i..<x.endIndex].foo() more implies
> “this will definitively replace the entire range from i to the end”?
>
> (with x[i…].foo() living in an unpleasant grey-area)
>
pretty much. We only want one "count" number floating around here so the
behavior is easy to think about, and since the source buffer already contains a
count we want the syntax to avoid implying a second quantity that might
contradict `source.count` as much as possible.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
