[swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Taylor Swift]

> On Oct 11, 2017, at 3:42 PM, Ben Cohen <ben_cohen at apple.com> wrote:
> 
> 
> 
>> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution <swift-evolution at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171011/f000f02d/attachment.html>