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

[Kelvin Ma]

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.brackettrozinsky at 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 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/proposa
>> ls/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/c8513772/attachment.html>