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/proposals/0172-one-sided-ranges.md Regards Anders > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution > <swift-evolution@swift.org> wrote: > > > > On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > 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), 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@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
