<div dir="ltr">I believe Kelvin was asking about the usage of ellipsis *by itself*, as in Xiaodi’s example, “newBuffer[...]”.<div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ICYMI, SE-0172 was the proposal of one sided range and it has been implemented as part of 4.0.<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0172-one-sided-<wbr>ranges.md</a><br>
<br>
<br>
Regards<br>
Anders<br>
<div class="HOEnZb"><div class="h5"><br>
> On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
> On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> 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/<wbr>deinitialization API for UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer.<br>
><br>
> 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.<br>
><br>
> newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])<br>
> newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..< self.zero])<br>
><br>
> Some other proposed APIs include using subscript notation, and writing a special buffer slice type and a corresponding protocol to handle this.<br>
><br>
> newBuffer[0... ].moveInitialize(from: self.buffer[self.zero... ])<br>
> newBuffer[self.zero ... self.zero << 1].moveInitialize(from: self.buffer[0 ..< self.zero])<br>
><br>
> Fully embracing slice notation and SwiftLint style, this could be:<br>
><br>
> newBuffer[...].moveInitialize(<wbr>from: buffer[zero...])<br>
> newBuffer[zero...].<wbr>moveInitialize(from: buffer[..<zero])<br>
><br>
> 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.<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>