[swift-evolution] SE-1084 (B): buffer pointer partial initialization API
kelvin13ma at gmail.com
Tue Oct 10 15:43:15 CDT 2017
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
>> 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 ..<
>> 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 <https://gist.github.com/kelvin13/0860334278aeab5c1cbaefbefb050268>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution