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 <kelvin1...@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.brackettrozin...@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@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@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
