[swift-evolution] SE-1084 (B): buffer pointer partial initialization API

Nevin Brackett-Rozinsky nevin.brackettrozinsky at gmail.com
Wed Oct 11 15:01:25 CDT 2017


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 at 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 at swift.org> wrote:
> >
> >
> >
> > 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
> 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171011/0800280b/attachment.html>


More information about the swift-evolution mailing list