On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote:
> Hi guys, after passing SE 184 (A) > <https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md>, > 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 > <https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md>, > 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]) 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. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution