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

[Kelvin Ma]

I should also add I think I remember the String people trying to add
collection[] empty subscripts to the language but I don’t remember that
ever going through.

On Wed, Oct 11, 2017 at 3:15 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:

> Yes, a 0-ary operator like that would have to be hard baked into the
> language itself. Of course, the subscript notation has much more serious
> problems, there is no way to allow one-sided subscripting, but disallow
> two-sided subscripting for the memory API, while still allowing two-sided
> subscripting for ordinary slicing operations. This is why I still think
> at:from: is the much better syntax.
>
> On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozinsky at gmail.com> wrote:
>
>> I believe Kelvin was asking about the usage of ellipsis *by itself*, as
>> in Xiaodi’s example, “newBuffer[...]”.
>>
>> Nevin
>>
>>
>> On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> ICYMI, SE-0172 was the proposal of one sided range and it has been
>>> implemented as part of 4.0.
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposa
>>> ls/0172-one-sided-ranges.md
>>>
>>>
>>> Regards
>>> Anders
>>>
>>> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu <xiaodi.wu at gmail.com>
>>> wrote:
>>> > On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> > Hi guys, after passing SE 184 (A), I want to get some community
>>> feedback on the next phase of our Swift pointer overhaul which is a partial
>>> initialization/deinitialization API for UnsafeMutableBufferPointer and
>>> UnsafeMutableRawBufferPointer.
>>> >
>>> > You can read about the originally proposed API in the original SE 184
>>> document, basically we use an at:from: system for binary memory state
>>> operations where the at: argument supplies the start position in the
>>> destination buffer, and the from: source argument supplies the number of
>>> elements to copy/move into the destination.
>>> >
>>> > newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
>>> > newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
>>> self.zero])
>>> >
>>> > Some other proposed APIs include using subscript notation, and writing
>>> a special buffer slice type and a corresponding protocol to handle this.
>>> >
>>> > newBuffer[0...                        ].moveInitialize(from:
>>> self.buffer[self.zero...   ])
>>> > newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
>>> self.buffer[0 ..< self.zero])
>>> >
>>> > Fully embracing slice notation and SwiftLint style, this could be:
>>> >
>>> > newBuffer[...].moveInitialize(from: buffer[zero...])
>>> > newBuffer[zero...].moveInitialize(from: buffer[..<zero])
>>> >
>>> > Is the solo ellipsis operator even valid Swift syntax? And I agree
>>> this would look nice, but as others have mentioned, Swift has the
>>> convention that the one-sided slice operators are equivalent to start ...
>>> endIndex and startIndex ... end. And that seems to strongly suggest that
>>> the method would initialize the entire range which is not what we want to
>>> communicate.
>>> >
>>> >
>>> > A hypothetical comparison of this API, the at:from: API, and the
>>> existing plain pointer API can be found in this basic Swift queue
>>> implementation here if anyone wants to see how this would look in “real”
>>> code. I’m interested in seeing which syntax and which API is preferred as
>>> well as what people would like to do with an expanded Swift buffer pointer
>>> toolbox.
>>> >
>>> > Would you mind rewriting these examples in a more common Swift style
>>> (for instance, SwiftLint/GitHub style)? Everyone is entitled to write code
>>> how they please, but it’s much easier to compare how things “look” when the
>>> overall formatting is more familiar.
>>> >
>>> > I mean the purpose of the example is to compare the call sites of the
>>> actual buffer methods. ignoring the function signatures and instead getting
>>> distracted by brace placement seems like the kind of bikeshedding we should
>>> be discouraging lol.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171011/39c88036/attachment.html>