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@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/ > 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution